| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 109112
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation detail (InsertPos
leaks though) and add methods to its interface for adding/finding specializations.
Simplifies its users a bit and we no longer need to replace specializations in the folding set with
their redeclarations. We just return the most recent redeclarations.
As a bonus, it fixes http://llvm.org/PR7670.
llvm-svn: 108832
|
|
|
|
|
|
|
| |
A ParmVarDecl instantiated from a FunctionProtoType may have Record as DeclContext,
in which case isStaticDataMember() will erroneously return true.
llvm-svn: 108692
|
|
|
|
| |
llvm-svn: 108340
|
|
|
|
|
|
|
| |
Some of the invariant checks for creating Record/Enum types don't hold true during PCH reading.
Introduce more suitable ASTContext::getRecordType() and getEnumType().
llvm-svn: 107598
|
|
|
|
|
|
|
|
| |
initializing so avoid
the invariant checks at NamespaceDecl::setAnonymousNamespace().
llvm-svn: 107566
|
|
|
|
| |
llvm-svn: 107479
|
|
|
|
| |
llvm-svn: 107268
|
|
|
|
| |
llvm-svn: 107267
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit 'introduces' a slightly different way to restore the state of the AST object.
It makes PCHDeclReader/PCHDeclWriter friends and gives them access to the private members of the object.
The rationale is to avoid using/modifying the AST interfaces for PCH read/write so that to:
-Avoid complications with objects that have side-effects during creation or when using some setters.
-Not 'pollute' the AST interface with methods only used by the PCH reader/writer
-Allow AST objects to be read-only.
llvm-svn: 107219
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, sub-stmts were stored as encountered and when they were placed in the Stmts stack we had to know what index
each stmt operand has. This complicated supporting variable sub-stmts and sub-stmts that were contained in TypeSourceInfos, e.g.
x = sizeof(int[1]);
would crash PCH.
Now, sub-stmts are stored in reverse order, from last to first, so that when reading them, in order to get the next sub-stmt we just
need to pop the last stmt from the stack. This greatly simplified the way stmts are written and read (just use PCHWriter::AddStmt and
PCHReader::ReadStmt accordingly) and allowed variable stmt operands and TypeSourceInfo exprs.
llvm-svn: 107087
|
|
|
|
| |
llvm-svn: 106998
|
|
|
|
| |
llvm-svn: 106996
|
|
|
|
| |
llvm-svn: 106995
|
|
|
|
| |
llvm-svn: 106860
|
|
|
|
| |
llvm-svn: 106832
|
|
|
|
| |
llvm-svn: 106831
|
|
|
|
| |
llvm-svn: 106727
|
|
|
|
| |
llvm-svn: 106726
|
|
|
|
| |
llvm-svn: 106625
|
|
|
|
| |
llvm-svn: 106552
|
|
|
|
| |
llvm-svn: 106534
|
|
|
|
| |
llvm-svn: 106404
|
|
|
|
|
|
| |
template reading from PCH.
llvm-svn: 106393
|
|
|
|
| |
llvm-svn: 106391
|
|
|
|
|
|
| |
the decl was read from a PCH file.
llvm-svn: 105852
|
|
|
|
| |
llvm-svn: 103390
|
|
|
|
|
|
| |
CXXExprWithTemporaries.
llvm-svn: 103387
|
|
|
|
| |
llvm-svn: 103376
|
|
|
|
| |
llvm-svn: 103375
|
|
|
|
| |
llvm-svn: 103374
|
|
|
|
|
|
|
| |
and deserialize as a CallExpr which is close, but ends up
deserializing with the wrong stmt class.
llvm-svn: 103371
|
|
|
|
|
|
| |
Andrew Sutton!
llvm-svn: 103301
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
llvm-svn: 102542
|
|
|
|
|
|
|
|
|
|
| |
statements. Instead of the @try having a single @catch, where all of
the @catch's were chained (using an O(n^2) algorithm nonetheless),
@try just holds an array of its @catch blocks. The resulting AST is
slightly more compact (not important) and better represents the actual
language semantics (good).
llvm-svn: 102221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:
t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
type 'int *' [-pedantic]
f(long_ptr);
^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
^
llvm-svn: 102038
|
|
|
|
|
|
|
| |
type..." with "initializing <type> with an expression of type...",
which reads better. Thanks to John for the improved wording.
llvm-svn: 100873
|
|
|
|
| |
llvm-svn: 100864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
llvm-svn: 100832
|
|
|
|
| |
llvm-svn: 99515
|
|
|
|
| |
llvm-svn: 98827
|
|
|
|
| |
llvm-svn: 98825
|
|
|
|
| |
llvm-svn: 98750
|
|
|
|
|
|
|
| |
changed, rather than trying to point out how it changed. The "why"
doesn't matter.
llvm-svn: 98725
|
|
|
|
|
|
| |
and grep that
llvm-svn: 98695
|
|
|
|
|
|
|
|
|
| |
buffer was invalid when it was created, and use that bit to always set
the "Invalid" flag according to whether the buffer is invalid. This
ensures that all accesses to an invalid buffer are marked invalid,
improving recovery.
llvm-svn: 98690
|
|
|
|
|
|
| |
recovery for those that need it.
llvm-svn: 98689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
presence or absence of header map arguments when using the precompiled
header would cause Clang to get confused about which headers had
already been included/imported, along with their controlling
macros. The fundamental problem is that the serialization of the
header search information was relying on the UIDs of FileEntry objects
at PCH generation time and PCH load time to be equivalent, which
effectively means that we had to probe the same files in the same
order. Differing header map arguments caused an extra FileEntry
lookup, but it's easy to imagine other minor command-line arguments
triggering this problem.
Header-search information is now encoded along with the
source-location entry for a file, so that we register information
about a file's properties as a header at the same time we create the
FileEntry for that file.
Fixes <rdar://problem/7743243>.
llvm-svn: 98636
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceManager's getBuffer() and, therefore, could fail, along with
Preprocessor::getSpelling(). Use the Invalid parameters in the literal
parsers (string, floating point, integral, character) to make them
robust against errors that stem from, e.g., PCH files that are not
consistent with the underlying file system.
I still need to audit every use caller to all of these routines, to
determine which ones need specific handling of error conditions.
llvm-svn: 98608
|
|
|
|
| |
llvm-svn: 97061
|