| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
llvm-svn: 122519
|
|
|
|
| |
llvm-svn: 122340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pack expansions, e.g. given
template<typename... Types> struct tuple;
template<typename... Types>
struct tuple_of_refs {
typedef tuple<Types&...> types;
};
the type of the "types" typedef is a PackExpansionType whose pattern
is Types&.
This commit introduces support for creating pack expansions for
template type arguments, as above, but not for any other kind of pack
expansion, nor for any form of instantiation.
llvm-svn: 122223
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
|
|
|
|
| |
llvm-svn: 121488
|
|
|
|
|
|
| |
BinaryTypeTraitExpr.
llvm-svn: 121298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used in a constructor initializer list:
struct X {
X() : au_i1(123) {}
union {
int au_i1;
float au_f1;
};
};
clang will now deal with au_i1 explicitly as an IndirectFieldDecl.
llvm-svn: 120900
|
|
|
|
| |
llvm-svn: 120588
|
|
|
|
|
|
|
|
|
|
| |
trap the serialized preprocessing records (macro definitions, macro
instantiations, macro definitions) from the generation of the
precompiled preamble, then replay those when walking the list of
preprocessed entities. This eliminates a bug where clang_getCursor()
wasn't able to find preprocessed-entity cursors in the preamble.
llvm-svn: 120396
|
|
|
|
| |
llvm-svn: 120297
|
|
|
|
|
|
| |
the result code of the stat to/from the PCH file since it is always 0.
llvm-svn: 120031
|
|
|
|
|
|
|
| |
its own header and giving it some more structure. No
functionality change.
llvm-svn: 120030
|
|
|
|
|
|
|
|
|
| |
NEON vector types need to be mangled in a special way to comply with ARM's ABI,
similar to some of the AltiVec-specific vector types. This patch is mostly
just renaming a bunch of "AltiVecSpecific" things, since they will no longer
be specific to AltiVec. Besides that, it just adds the new "NeonVector" enum.
llvm-svn: 118724
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
llvm-svn: 118385
|
|
|
|
| |
llvm-svn: 118305
|
|
|
|
|
|
|
|
| |
e.g. #pragma clang diagnostic can be used in a PCH.
Fixes rdar://8435969.
llvm-svn: 118303
|
|
|
|
| |
llvm-svn: 117770
|
|
|
|
|
|
| |
the performance of C++ PCH and reducing stack depth in the reader.
llvm-svn: 117732
|
|
|
|
|
|
|
|
| |
DeclContext,
meaning we need to rewrite its name lookup table in a chained PCH.
llvm-svn: 117536
|
|
|
|
| |
llvm-svn: 117535
|
|
|
|
| |
llvm-svn: 117534
|
|
|
|
|
|
| |
chained PCH.
llvm-svn: 117533
|
|
|
|
|
|
| |
definition was completed.
llvm-svn: 117240
|
|
|
|
|
|
|
|
|
| |
completed.
In that case a chained PCH will record the updates to the DefinitionData pointer of forward references.
If a forward reference mutated into a definition re-write it into the chained PCH, this is too big of a change.
llvm-svn: 117239
|
|
|
|
|
|
| |
that will be replaced in the chained PCH.
llvm-svn: 117238
|
|
|
|
| |
llvm-svn: 117237
|
|
|
|
|
|
|
| |
- Pass around RecordDataImpl instead of the concrete RecordData so that any SmallVector can be used.
- Move ASTDeclWriter::WriteCXXDefinitionData to ASTWriter::AddCXXDefinitionData.
llvm-svn: 117236
|
|
|
|
|
|
|
|
|
|
|
|
| |
committed after
its initial creation/deserialization and store the changes in a chained PCH.
The idea is that the AST entities call methods on the ASTMutationListener to give notifications
of changes; the PCHWriter implements the ASTMutationListener interface and stores the incremental changes
of the updated entity. WIP
llvm-svn: 117235
|
|
|
|
|
|
|
|
|
|
| |
This adds an option to set the _MSC_VER macro without
recompiling. This is very useful when testing compatibility
with the Windows SDK and c++stdlib headers.
-fmsc-version=<version> (defaults to VS2003 (1300))
llvm-svn: 116999
|
|
|
|
| |
llvm-svn: 116990
|
|
|
|
|
|
|
|
|
| |
inclusion directives, keeping track of every #include, #import,
etc. in the translation unit. We keep track of the source location and
kind of the inclusion, how the file name was spelled, and the
underlying file to which the inclusion resolved.
llvm-svn: 116952
|
|
|
|
|
|
|
|
|
| |
declaration block instead of trying to create another block.
The new block was messing with the assumption that after decls block comes the stmts block.
Fixes http://llvm.org/PR8406
llvm-svn: 116737
|
|
|
|
|
|
| |
QualifierInfos (rdar://8513756).
llvm-svn: 116598
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iterate over them,
instead of deserializing the complete declaration context of the record.
Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration
that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods.
Fix this by allow deserialization of just the fields when we want to iterate over them.
Progress for rdar://7260160.
llvm-svn: 116507
|
|
|
|
|
|
|
| |
'super' as receiver of property or a setter/getter
methods. //rdar: //8525788
llvm-svn: 116483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
following amusing sequence:
- AST writing schedules writing a type X* that it had never seen
before
- AST writing starts writing another declaration, ends up
deserializing X* from a prior AST file. Now we have two type IDs for
the same type!
- AST writer tries to write X*. It only has the lower-numbered ID
from the the prior AST file, so references to the higher-numbered ID
that was scheduled for writing go off into lalaland.
To fix this, keep the higher-numbered ID so we end up writing the type
twice. Since this issue occurs so rarely, and type records are
generally rather small, I deemed this better than the alternative: to
keep a separate mapping from the higher-numbered IDs to the
lower-numbered IDs, which we would end up having to check whenever we
want to deserialize any type.
Fixes <rdar://problem/8511624>, I think.
llvm-svn: 115647
|
|
|
|
|
|
| |
it into a chained PCH file.
llvm-svn: 115527
|
|
|
|
|
|
| |
the "detailed" preprocessing record.
llvm-svn: 115417
|
|
|
|
|
|
|
|
|
|
| |
auto f(int) -> int
from Daniel Wallin!
(With a few minor bug fixes from me).
llvm-svn: 115322
|
|
|
|
|
|
|
| |
file is somehow changed in a chained PCH file, make sure that we write
out the macro definition. Fixes part of <rdar://problem/8499034>.
llvm-svn: 115259
|
|
|
|
| |
llvm-svn: 114922
|
|
|
|
|
|
| |
them the correct IDs. Fixes a crash in XCode.
llvm-svn: 114913
|
|
|
|
| |
llvm-svn: 114575
|
|
|
|
| |
llvm-svn: 114014
|
|
|
|
| |
llvm-svn: 113185
|
|
|
|
| |
llvm-svn: 112820
|
|
|
|
|
|
| |
functionality changed.
llvm-svn: 112040
|
|
|
|
| |
llvm-svn: 112026
|
|
|
|
|
|
| |
the chain. This ought to finish C++ chained PCH support.
llvm-svn: 111986
|
|
|
|
|
|
| |
If someone wants to fix this some other way....
llvm-svn: 111905
|