| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
which allows grouping parens in an abstract-pack-declarator. This was already
mostly implemented, but missed some cases. Add an ExtWarn for use of this
extension until CWG ratifies it.
llvm-svn: 175660
|
|
|
|
|
|
|
| |
diagnose attributes on alias declarations, using directives, and attribute
declarations.
llvm-svn: 175649
|
|
|
|
|
|
|
|
|
| |
Now correctly indents (again):
a = a + "a"
"a"
"a";
llvm-svn: 175630
|
|
|
|
|
|
|
|
|
| |
We now indent the following correctly:
1. some + "literal" /* comment */
"literal";
2. breaking string literals after which we have another string literal.
llvm-svn: 175628
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the code author decides to put empty lines anywhere into the code we
should treat them equally, i.e. reduce them to the configured
MaxEmptyLinesToKeep.
With this change, we e.g. keep the newline in:
SomeType ST = {
// First value
a,
// Second value
b
};
llvm-svn: 175620
|
|
|
|
|
|
|
|
|
|
| |
An alternative strategy to calculating the break on demand when hitting
a token that would need to be broken would be to put all possible breaks
inside the token into the optimizer.
Currently only supports breaking at spaces; more break points to come.
llvm-svn: 175613
|
|
|
|
|
|
| |
See r175462 for another example/more details.
llvm-svn: 175594
|
|
|
|
|
|
| |
<rdar://problem/11540697>
llvm-svn: 175588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
llvm-svn: 175587
|
|
|
|
| |
llvm-svn: 175586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
llvm-svn: 175585
|
|
|
|
|
|
|
|
|
|
|
| |
RegionStoreManager::getInterestingValues() returns a pointer to a
std::vector that lives inside a DenseMap, which is constructed on demand.
However, constructing one such value can lead to constructing another
value, which will invalidate the reference created earlier.
Fixed by delaying the new entry creation until the function returns.
llvm-svn: 175582
|
|
|
|
|
|
|
|
| |
attributes yet, so just issue the appropriate diagnostics. Also generalize the
fixit for attributes-in-the-wrong-place code and reuse it here, if attributes
are placed after the access-specifier or 'virtual' in a base specifier.
llvm-svn: 175575
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a base object is at a 0 offset, RegionStoreManager may find a lazy
binding for the entire object, then try to attach a FieldRegion or
grandparent CXXBaseObjectRegion on top of that (skipping the intermediate
region). We now preserve as many layers of base object regions necessary
to make the types match.
<rdar://problem/13239840>
llvm-svn: 175556
|
|
|
|
|
|
| |
.. and a test that triggers it in valid albeit questionable code.
llvm-svn: 175554
|
|
|
|
| |
llvm-svn: 175552
|
|
|
|
|
|
| |
Module::getExportedModules() so it can be reused.
llvm-svn: 175548
|
|
|
|
| |
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
|