| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 175539
|
|
|
|
|
|
|
|
|
| |
We can now format:
#define A template <typename T>
Before this created a segfault :-/.
llvm-svn: 175533
|
|
|
|
|
|
| |
make Clang look for the default sanitizer-specific blacklist in the resource directory.
llvm-svn: 175505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key bug was
if (Other.StartOfLineLevel < StartOfLineLevel) ..
instead of
if (Other.StartOfLineLevel != StartOfLineLevel) ..
Also cleaned up the function to be more consistent in the comparisons.
llvm-svn: 175500
|
|
|
|
| |
llvm-svn: 175492
|
|
|
|
|
|
| |
assigning in the parameter Fixits. This fixes several failed assertions with MSVC debug builds.
llvm-svn: 175483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We treat this as an alternative to -fvisibility=<?>
which changes the default value visibility to "hidden"
and the default type visibility to "default".
Expose a -cc1 option for changing the default type
visibility, repurposing -fvisibility as the default
value visibility option (also setting type visibility
from it in the absence of a specific option).
rdar://13079314
llvm-svn: 175480
|
|
|
|
|
|
|
|
| |
not the global visibility mode.
Noticed by inspection.
llvm-svn: 175479
|
|
|
|
| |
llvm-svn: 175477
|
|
|
|
| |
llvm-svn: 175471
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
|
|
|
|
|
|
| |
a small test case). // rdar://13178483.
llvm-svn: 175450
|
|
|
|
| |
llvm-svn: 175448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
module deserialization.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaa->aaaaaaa->aaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)->aaaaaaaa(aaaaaaaaaaaaaaa);
After:
aaaaaaa->aaaaaaa
->aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
->aaaaaaaa(aaaaaaaaaaaaaaa);
llvm-svn: 175441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, other parameters can be quite hidden.
Reformatted unittests/Format/FormatTest.cpp after this.
Before:
someFunction("Always break between multi-line"
" string literals", and, other, parameters);
After:
someFunction("Always break between multi-line"
" string literals",
and, other, parameters);
llvm-svn: 175436
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa).aaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaa).aaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa)
.aaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa)
.aaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 175432
|
|
|
|
|
|
| |
<rdar://problem/13213575>.
llvm-svn: 175425
|
|
|
|
| |
llvm-svn: 175418
|
|
|
|
| |
llvm-svn: 175414
|
|
|
|
| |
llvm-svn: 175412
|
|
|
|
| |
llvm-svn: 175411
|
|
|
|
| |
llvm-svn: 175410
|
|
|
|
| |
llvm-svn: 175409
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 175389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 175386
|
|
|
|
|
|
| |
Patch by Alexander Zinenko.
llvm-svn: 175376
|
|
|
|
| |
llvm-svn: 175374
|
|
|
|
| |
llvm-svn: 175331
|
|
|
|
|
|
|
| |
linkonce_odr. Emit construction vtables as internal in this case, since the ABI
does not guarantee that they will be availble externally.
llvm-svn: 175330
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 175329
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 175326
|
|
|
|
|
|
|
| |
The back-end will use these values to reconfigure code generation for different
features.
llvm-svn: 175308
|
|
|
|
|
|
|
| |
an ivar of type pointer to a typedef'ed object.
// rdar://13190095
llvm-svn: 175298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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();
llvm-svn: 175291
|
|
|
|
| |
llvm-svn: 175289
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
ostream &operator
<<(ostream &out, some::ns::SomeReallyLongType WithSomeReallyLongValue);
After:
ostream &operator<<(ostream &out,
some::ns::SomeReallyLongType WithSomeReallyLongValue);
llvm-svn: 175286
|
|
|
|
|
|
|
|
| |
while trying to do error recovery.
rdar://13207886
llvm-svn: 175282
|
|
|
|
|
|
|
| |
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.
llvm-svn: 175281
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 175277
|
|
|
|
|
|
|
| |
cast<ObjCObjectPointerType> doesn't look through sugar, getAs does.
Fixes PR15257.
llvm-svn: 175272
|
|
|
|
|
|
| |
microsoft; also fix vdtor calls for the ARM ABI
llvm-svn: 175271
|
|
|
|
| |
llvm-svn: 175265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is almost always more readable.
Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
? aaaaaaaaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
? aaaaaaaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 175262
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This just adds a very simple check that if a DerivedToBase CastExpr is
operating on a value with known C++ object type, and that type is not the
base type specified in the AST, then the cast is invalid and we should
return UnknownVal.
In the future, perhaps we can have a checker that specifies that this is
illegal, but we still shouldn't assert even if the user turns that checker
off.
PR14872
llvm-svn: 175239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...after a host of optimizations related to the use of LazyCompoundVals
(our implementation of aggregate binds).
Originally applied in r173951.
Reverted in r174069 because it was causing hangs.
Re-applied in r174212.
Reverted in r174265 because it was /still/ causing hangs.
If this needs to be reverted again it will be punted to far in the future.
llvm-svn: 175234
|