| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 216370
|
| |
|
|
|
|
|
|
| |
type encoding because in certain cases, such as for vector
types, because we still haven't designed encoding for them.
rdar://9255564
llvm-svn: 216301
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 216183
|
| |
|
|
|
|
|
| |
A typedef of a typedef should have AlignIsRequired if *either* typedef
has an AlignAttr attached to it.
llvm-svn: 214698
|
| |
|
|
|
|
|
|
| |
FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care
about the other ExtProtoInfo bits and just want to talk about the exception
specification.
llvm-svn: 214450
|
| |
|
|
|
|
|
|
|
|
| |
Iterator invalidation issues already force us to do one lookup and one
insert.
Don't use the particular bit-pattern of the 'Align' field to determine
whether or not we have already inserted into the TypeInfo DenseMap;
instead ask for an iterator to the TypeInfo entry.
llvm-svn: 214293
|
| |
|
|
|
|
| |
Thanks to David Balkie for the suggestion.
llvm-svn: 214286
|
| |
|
|
| |
llvm-svn: 214281
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI has a notion of 'required alignment' for fields; this
alignment supercedes pragma pack directives.
MSVC takes into account alignment attributes on typedefs when
determining whether or not a field has a certain required alignment.
Do the same in clang by tracking whether or not we saw such an attribute
when calculating the type's bitwidth and alignment.
This fixes PR20418.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4714
llvm-svn: 214274
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
members (PR20140)
This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.
It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.
Differential Revision: http://reviews.llvm.org/D4563
llvm-svn: 213304
|
| |
|
|
|
|
| |
range-based for loops instead. No functional changes intended.
llvm-svn: 213095
|
| |
|
|
| |
llvm-svn: 212667
|
| |
|
|
|
|
|
| |
It is useful to get the property encoding for an ObjC type without a full
ObjCPropertyDecl.
llvm-svn: 212496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Do not store duplicate parents when memoization data is available.
This does not solve the duplication problem, but ameliorates it.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D4124
llvm-svn: 210902
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The backing store of thread local variables is internal for OS X and all
accesses must go through the thread wrapper.
However, individual TUs may have inlined through the thread wrapper.
To fix this, give the thread wrapper functions WeakAnyLinkage. This
prevents them from getting inlined into call-sites.
This fixes PR19989.
llvm-svn: 210632
|
| |
|
|
|
|
|
| |
preferred-alignment transformations. Corrects alignof(T[]) to return
alignof(T) in all cases, as required by relevant standards.
llvm-svn: 210609
|
| |
|
|
|
|
|
| |
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.
llvm-svn: 210608
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC delays parsing of default arguments until instantiation. If the
default argument is never used, it is never parsed. We don't model
this.
Instead, if lookup of a type name fails in a template argument context,
we form a DependentNameType, which will be looked up at instantiation
time.
This fixes errors about 'CControlWinTraits' in atlwin.h.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3995
llvm-svn: 210382
|
| |
|
|
|
|
|
| |
than omitting it the first time we see a decltype type with a particular
expression.
llvm-svn: 210283
|
| |
|
|
|
|
|
|
|
|
|
| |
On test files I ran this on, memory consumption overall went down from
2.5G to 2G, without performance regressions.
I also investigated making DynTypedNode by itself smaller (by pulling
out pointers for everything that doesn't fit in 8 bytes). This led to
another 200-300MB saved, but also introduced a significant regression in
performance due to the memory management overhead.
llvm-svn: 209297
|
| |
|
|
| |
llvm-svn: 209289
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
|
| |
|
|
|
|
|
|
| |
This is a step towards handling these attributes on classes (PR11170).
Differential Revision: http://reviews.llvm.org/D3772
llvm-svn: 208925
|
| |
|
|
|
|
|
|
|
|
|
| |
GetGVALinkageForFunction handles TSK_ExplicitInstantiationDeclaration
twice, remove the redundant code trying to handle it again.
While we are here, update the reference we make to the standard. It
seems like another paragraph was added causing this text to get
renumbered.
llvm-svn: 208850
|
| |
|
|
|
|
| |
class.
llvm-svn: 208687
|
| |
|
|
| |
llvm-svn: 208517
|
| |
|
|
|
|
|
|
|
| |
Having various possible states of initialization following construction doesn't
add value here.
Also remove the unused size_reserve parameter.
llvm-svn: 207897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
|
| |
|
|
|
|
|
|
|
|
| |
parameters from the original FullComment,
if the parameters are not already set (e.g. because it is a typedef).
Fixes crash of rdar://16128173
llvm-svn: 207382
|
| |
|
|
|
|
|
|
|
| |
When instantiating an array that has an alignment attribute on it, we
were looking through the array type and only considering the element
type for the resulting alignment. We need to make sure we take the
array's requirements into account too.
llvm-svn: 206317
|
| |
|
|
|
|
|
| |
when bridged Objective-C type conforms to the protocols in CF types's
Objective-C class. // rdar://16393330
llvm-svn: 205659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
llvm-svn: 205485
|
| |
|
|
|
|
| |
'readonly' property. // rdar://16136439
llvm-svn: 205477
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
|
| |
|
|
|
|
| |
Previously we would only attach comments to the typedef.
llvm-svn: 204942
|
| |
|
|
|
|
|
|
|
| |
correctly order comments in SourceManager::isBeforeInTranslationUnit() order
Unfortunately, this is not as simple as it was implemented previously, and
actually requires doing a merge sort.
llvm-svn: 204936
|
| |
|
|
|
|
| |
qual_end() with iterator_range quals(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204048
|
| |
|
|
|
|
| |
iterator_range quals(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204047
|
| |
|
|
|
|
| |
param_type_end() with iterator_range param_types(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204045
|
| |
|
|
|
|
| |
propimpl_end() with iterator_range property_impls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203930
|
| |
|
|
|
|
| |
protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203922
|
| |
|
|
|
|
| |
protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203863
|
| |
|
|
|
|
| |
known_extensions_end() with iterator_range known_extensions(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203857
|
| |
|
|
|
|
| |
visible_categories_end() with iterator_range visible_categories(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203851
|
| |
|
|
|
|
| |
with iterator_range ivars(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203849
|
| |
|
|
|
|
| |
all_referenced_protocol_begin() and all_referenced_protocol_end() with iterator_range all_referenced_protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203848
|
| |
|
|
|
|
| |
with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203808
|
| |
|
|
|
|
| |
iterator_range bases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203803
|
| |
|
|
|
|
| |
iterator_range fields(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203355
|
| |
|
|
|
|
| |
iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203250
|