if the nul-terminatedness property is important for clients.
Also, don't return the same CXString multiple times. This did not create a
correctness issue in practice because the CXString was of an CXS_Unmanaged
kind, and destruction was a no-op.
llvm-svn: 175455
Also, GetElementPtrInst::getType() method returns SequentialType now, instead of
PointerType. There wasn't any issue yet, so no testcase attached.
llvm-svn: 175452
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.
llvm-svn: 175447
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();
llvm-svn: 175444
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.
llvm-svn: 175440
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) {}
llvm-svn: 175439
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.
llvm-svn: 175438
We already use features from 2.8.6, this just gives a slightly more friendly
message when the dependency isn't met.
Patch from Keith Walker.
llvm-svn: 175434
Profiling tests *do* need a JIT. They'll pass if a cross-compiler targetting
AArch64 by default has been built, but fail if a native AArch64 compiler has
been build. Therefore XFAIL is inappropriate and we mark them unsupported.
ExecutionEngine tests are JIT by definition, they should also be unsupported.
Transforms/LICM only uses the interpreter to check the output is still sane
after optimisation. It can be switched to use an interpreter.
llvm-svn: 175433
Previously we seemed to be assuming that all functions were definitions and all
methods were declarations. This may be consistent with how Clang uses DIBuilder
but doesn't have to be true of all clients (such as DragonEgg).
llvm-svn: 175423
at this time, llvm is generating a different but equivalent pattern
that would lead to this instruction. I am trying to think of a way
to get it to generate this. If I can't, I may just remove the pseudo.
llvm-svn: 175419
This expansion will be moved to expandISelPseudos as soon as I can figure
out how to do that. There are other instructions which use this
ExpandFEXT_T8I816_ins and as soon as I have finished expanding them all,
I will delete the macro asm string text so it has no way to be used
in the future.
llvm-svn: 175413
Dmitri Gribenko