This commit introduces a set of related changes to ensure that the
declaration that shows up in the identifier chain after deserializing
declarations with a given identifier is, in fact, the most recent
declaration. The primary change involves waiting until after we
deserialize and wire up redeclaration chains before updating the
identifier chains. There is a minor optimization in here to avoid
recursively deserializing names as part of looking to see whether
top-level declarations for a given name exist.
A related change that became suddenly more urgent is to property
record a merged declaration when an entity first declared in the
current translation unit is later deserialized from a module (that had
not been loaded at the time of the original declaration). Since we key
off the canonical declaration (which is parsed, not from an AST file)
for emitted redeclarations, we simply record this as a merged
declaration during AST writing and let the readers merge them.
Re-fixes <rdar://problem/13189985>, presumably for good this time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175447 91177308-0d34-0410-b5e6-96231b3b80d8
In builder-type calls, it can be very confusing to just indent
parameters from the start of the line. Instead, indent 4 from the
correct function call.
Before:
aaaaaaaaaaaaaaaaaaa()->aaaaaa(bbbbb)->aaaaaaaaaaaaaaaaaaa( // break
aaaaaaaaaaaaaa);
aaaaaaaaaaaaaaaaaaaaaaa *aaaaaaaaa = aaaaaa->aaaaaaaaaaaa()->aaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
->aaaaaaaaaaaaaaaaa();
After:
aaaaaaaaaaaaaaaaaaa()->aaaaaa(bbbbb)->aaaaaaaaaaaaaaaaaaa( // break
aaaaaaaaaaaaaa);
aaaaaaaaaaaaaaaaaaaaaaa *aaaaaaaaa = aaaaaa->aaaaaaaaaaaa()
->aaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
->aaaaaaaaaaaaaaaaa();
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175444 91177308-0d34-0410-b5e6-96231b3b80d8
An unwrapped line can get moved around if there is no newline before
it and the previous line was formatted.
Example:
template<typename T> // Cursor is on this line when hitting "format"
T *getFETokenInfo() const { return static_cast<T*>(FETokenInfo); }
"return .." is the second unwrapped line in this scenario. I does not
touch any reformatted region. Thus, the result of formatting is:
template <typename T> T *getFETokenInfo() const { return static_cast<T *>(FETokenInfo); }
After second format (and arguably desired end-result):
template <typename T> T *getFETokenInfo() const {
return static_cast<T *>(FETokenInfo);
}
This fixes: llvm.org/PR15060.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175440 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/PR15248.
Before:
Test::Test(int b) : a(b *b) {}
for (int i = 0; i < a *a; ++i) {}
After:
Test::Test(int b) : a(b * b) {}
for (int i = 0; i < a * a; ++i) {}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175439 91177308-0d34-0410-b5e6-96231b3b80d8
This allows Clang to detect and deal wih __atomic_* operations properly on
AArch64. Previously we produced an error when encountering them at high
optimisation levels.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175438 91177308-0d34-0410-b5e6-96231b3b80d8
bitfield related issues.
The original commit broke Takumi's builder. The bug was caused by bitfield sizes
being determined by their underlying type, rather than the field info. A similar
issue with bitfield alignments showed up on closer testing. Both have been fixed
in this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175389 91177308-0d34-0410-b5e6-96231b3b80d8
An ivar ofset cannot be marked as invariant load in all cases. The ivar offset
is a lazily initialised constant, which is dependent on an objc_msgSend
invocation to perform a fixup of the offset. If the load is being performed on
a method implemented by the class then this load can safely be marked as an
inviarant because a message must have been passed to the class at some point,
forcing the ivar offset to be resolved.
An additional heuristic that can be used to identify an invariant load would be
if the ivar offset base is a parameter to an objc method. However, without the
parameters available at hand, this is currently not possible.
Reviewed-by: John McCall <rjmccall@apple.com>
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175386 91177308-0d34-0410-b5e6-96231b3b80d8
Neither of the current clients of CFGRecStmtDeclVisitor are doing
anything with typedefs, so I assume type aliases (C++11 "using")
can be safely ignored. This was causing assertion failures in
the analyzer.
<rdar://problem/13228440>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175335 91177308-0d34-0410-b5e6-96231b3b80d8
linkonce_odr. Emit construction vtables as internal in this case, since the ABI
does not guarantee that they will be availble externally.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175330 91177308-0d34-0410-b5e6-96231b3b80d8
until recursive loading is finished.
Otherwise we may end up with a template trying to deserialize a template
parameter that is in the process of getting loaded.
rdar://13135282
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175329 91177308-0d34-0410-b5e6-96231b3b80d8
for distinguishing type vs. value visibility.
The changes to the visibility of explicit specializations
are intentional. The change to the "ugly" test case is
a consequence of a sensible implementation, and I am happy
to argue that this is better behavior. Other changes may
or may not be intended; it is quite difficult to divine
intent from some of the code I altered.
I've left behind a comment which I hope explains the
philosophy behind visibility computation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175326 91177308-0d34-0410-b5e6-96231b3b80d8
Adds a function clang_getTypeSpelling(CXType CT) that returns
a CXString containing the underlying type.
Patch by Ben Gertzfield.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175299 91177308-0d34-0410-b5e6-96231b3b80d8
The current heuristic assumes that there can't be binary operators in
builder-type calls (excluding assigments). However, it also excluded
< and > in general, which is wrong. Now they are only excluded if they
are template parameters.
Before:
return aaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa()i
.aaaaaa() < aaaaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa();
After:
return aaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa() <
aaaaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa();
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175291 91177308-0d34-0410-b5e6-96231b3b80d8
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175281 91177308-0d34-0410-b5e6-96231b3b80d8
This got lost and was untested as the same effect is achieved by
avoiding bin packing, which is active in Google style by default.
However, moving forward, we want more control over the bin packing
option(s) and thus, this flag should work as expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175277 91177308-0d34-0410-b5e6-96231b3b80d8
Fariborz Jahanian
Argyrios Kyrtzidis
Douglas Gregor
Daniel Jasper
Tim Northover
David Blaikie
Ted Kremenek
Eric Christopher
Dmitri Gribenko
Lang Hames
James Dennett
Saleem Abdulrasool
Jordan Rose
Richard Smith
John McCall
Chad Rosier
Bill Wendling
Enea Zaffanella