In general, we like to avoid line breaks like:
...
SomeParameter, OtherParameter).DoSomething(
...
as they tend to make code really hard to read (how would you even indent the
next line?). Previously we have implemented this in a hacky way, which has now
shown to lead to problems. This fixes a few weird looking formattings, such as:
Before:
aaaaa(
aaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.aaaaa(aaaaa),
aaaaaaaaaaaaaaaaaaaaa);
After:
aaaaa(aaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa).aaaaa(aaaaa),
aaaaaaaaaaaaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182731 91177308-0d34-0410-b5e6-96231b3b80d8
If -fsanitize=leak is specified, link the program with the
LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified,
because AddressSanitizer has this functionality built in.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182729 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
@{ NSFontAttributeNameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
: regularFont, };
Now:
@{ NSFontAttributeNameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee :
regularFont, };
':'s in dictionary literals (and the corresponding {}s) are now marked as
TT_ObjCDictLiteral too, which makes further improvements to dict literal
layout possible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182716 91177308-0d34-0410-b5e6-96231b3b80d8
John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or a
function that returns it.
One way to implement this would be to recursively look for local
types. This would look a lot like the linkage computation itself for
types.
To avoid code duplication and utilize the existing linkage cache, this
patch just makes the computation of "type with no linkage but
externally visible because it is from an inline function" part of the
linkage computation itself.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182711 91177308-0d34-0410-b5e6-96231b3b80d8
When x is empty, x ## is suppressed, and when y gets expanded, the fact that it follows ## is not
available in the macro expansion result. The macro definition can be checked instead, the ## will
be available there regardless of what x expands to.
Fixes http://llvm.org/PR12767
Patch by Harald van Dijk!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182699 91177308-0d34-0410-b5e6-96231b3b80d8
When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.
By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.
<rdar://problem/13978414>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182677 91177308-0d34-0410-b5e6-96231b3b80d8
The new edge algorithm would keep track of the previous location in each
location context, so that it could draw arrows coming in and out of each
inlined call. However, it tried to access the location of the call before
it was actually set (at the CallEnter node). This only affected
unterminated calls at the end of a path; calls with visible exit nodes
already had a valid location.
This patch ditches the location context map, since we're processing the
nodes in order anyway, and just unconditionally updates the PrevLoc
variable after popping out of an inlined call.
<rdar://problem/13983470>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182676 91177308-0d34-0410-b5e6-96231b3b80d8
To make this more consistent with 'getOrCreateType' & clarify the
distinction between the two. The only thing I couldn't quite communicate
in the name is that getOrCreateTypeDeclaration may actually produce a
full definition (in -fno-limit-debug-info) but the point is to call it
whenever only a declaration is needed & the implementation can choose
whether to provide a declaration or definition.
(also, unfortunately, getOrCreateType can produce declarations too - we
should sure this up by making it not do that - any caller that can
tolerate a declaration should be calling getOrCreateTypeDeclaration
instead)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182674 91177308-0d34-0410-b5e6-96231b3b80d8
Perhaps we should just suppress this, rather than erroring, but since we
have the infrastructure for it I figured I'd use it - if this is
determined to be not the right thing we should probably remove that
infrastructure entirely. I guess it's lying around from the early days
of implementing debug info support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182673 91177308-0d34-0410-b5e6-96231b3b80d8
This removes a FIXME in CodeGenModule::SetLLVMFunctionAttributesForDefinition.
When a function is declared cold we can now generate the IR attribute in
addition to marking the function to be optimized for size.
I tried adding a separate CHECK in the existing test, but it was
failing. I suppose CHECK matches one line exactly once? This would be
a problem if the attributes are listed in a different order, though they
seem to be sorted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182666 91177308-0d34-0410-b5e6-96231b3b80d8
for labels in inline assembly that aren't in the lookup tables. E.g.,
__asm {
a:
jmp a
}
rdar://13983623
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182659 91177308-0d34-0410-b5e6-96231b3b80d8
Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182645 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we started sequences to align for single line comments when
the previous line had a trailing comment, but the sequence was broken
for other reasons.
Now we re-format:
// a
// b
f(); // c
to:
// a
// b
f(); // c
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182608 91177308-0d34-0410-b5e6-96231b3b80d8
Now correctly leaves:
f(); // comment
// comment
g(); // comment
... alone if the middle comment was aligned with g() before formatting.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182605 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would align:
f(); // comment
// other comment
g();
Even if // other comment was at the start of the line. Now we do not
align trailing comments if they have been already aligned correctly
with the next line.
Thus,
f(); // comment
// other comment
g();
will not be changed, while:
f(); // comment
// other commment
g();
will lead to the two trailing comments being aligned.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182577 91177308-0d34-0410-b5e6-96231b3b80d8
Replaces the use of WhitespaceStart + WhitspaceLength.
This made a bug in the formatter obvous where we would incorrectly
calculate the next column.
FIXME: There's a similar bug left regarding TokenLength. We should
probably also move to have a TokenRange instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182572 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
vector<int> x { 1, 2, 3 };
After:
vector<int> x{ 1, 2, 3 };
Also add a style option to remove the spaces inside braced lists,
so that the above becomes:
std::vector<int> v{1, 2, 3};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182570 91177308-0d34-0410-b5e6-96231b3b80d8
Allows formatting of C++11 braced init list constructs, like:
vector<int> v { 1, 2, 3 };
f({ 1, 2 });
This involves some changes of how tokens are handled in the
UnwrappedLineFormatter. Note that we have a plan to evolve the
design of the token flow into one where we create all tokens
up-front and then annotate them in the various layers (as we
currently already have to create all tokens at once anyway, the
current abstraction does not help). Thus, this introduces
FIXMEs towards that goal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182568 91177308-0d34-0410-b5e6-96231b3b80d8
specialization with modules enabled. Just don't merge them at all for now;
we'll revisit this when support for template merging is added.
In passing, make Decl::dump() a little safer to use with PCH/modules, by making
it not deserialize any additional declarations. From a debugger you can call
decls_begin() or similar first if you want to dump all child decls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182544 91177308-0d34-0410-b5e6-96231b3b80d8
* Treat _Atomic(T) as a literal type if T is a literal type.
* Evaluate expressions of this type properly.
* Fix a lurking bug where we built completely bogus ASTs for converting to
_Atomic types in C++ in some cases, caught by the tests for this change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182541 91177308-0d34-0410-b5e6-96231b3b80d8
- The return type should be a pointer to the class type.
- Make the condition more specific.
rdar://problem/13359718
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182504 91177308-0d34-0410-b5e6-96231b3b80d8
These are legitimate control-flow edges, but visually they add
no value.
Implements <rdar://problem/13941325>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182502 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, blocks instantiated in templates lose their "signature as
written"; it's not clear if this is intentional. Change the analyzer's
use of BlockDecl::getSignatureAsWritten to check whether or not the
signature is actually there.
<rdar://problem/13954714>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182497 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of selectively storing some changes and directly generating
replacements for others, we now notify the WhitespaceManager of the
whitespace before every token (and optionally with more changes inside
tokens).
Then, we run over all whitespace in the very end in original source
order, where we have all information available to correctly align
comments and escaped newlines.
The future direction is to pull more of the comment alignment
implementation that is now in the BreakableToken into the
WhitespaceManager.
This fixes a bug when aligning comments or escaped newlines in unwrapped
lines that are handled out of order:
#define A \
f({ \
g(); \
});
... now gets correctly layouted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182467 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format was a bit too aggressive when trying to keep labels and
values on the same line.
Before:
llvm::outs()
<< "aaaaaaaaaaaaaaaaaaa: " << aaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
llvm::outs() << "aaaaaaaaaaaaaaaaaaa: "
<< aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182458 91177308-0d34-0410-b5e6-96231b3b80d8
This only affects styles that prevent bin packing. There, a break after
a template declaration also forced a line break after the function name.
Before:
template <class SomeType, class SomeOtherType>
SomeType
SomeFunction(SomeType Type, SomeOtherType OtherType) {}
After:
template <class SomeType, class SomeOtherType>
SomeType SomeFunction(SomeType Type, SomeOtherType OtherType) {}
This fixes llvm.org/PR16072.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182457 91177308-0d34-0410-b5e6-96231b3b80d8
Reduce the preference for breaking before a trailing 'const' according
to review comments on r182362.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182455 91177308-0d34-0410-b5e6-96231b3b80d8
If clang-format is confronted with long and deeply nested lines (e.g.
complex static initializers or function calls), it can currently try too
hard to find the optimal solution and never finish. The reason is that
the memoization does not work effectively for deeply nested lines.
This patch removes an earlier workaround and instead opts for
accepting a non-optimal solution in rare cases. However, it only does
so only in cases where it would have to analyze an excessive number of
states (currently set to 10000 - the most complex line in Format.cpp
requires ~800 states) so this should not change the behavior in a
relevant way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182449 91177308-0d34-0410-b5e6-96231b3b80d8
The crash is triggered by the newly added option (-analyzer-config report-in-main-source-file=true) introduced in r182058.
Note, ideally, we’d like to report the issue within the main source file here as well.
For now, just do not crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182445 91177308-0d34-0410-b5e6-96231b3b80d8
*that* easy...
Try a bit harder to disambiguate. This is mostly straightforward, but for
=-style initializers, we actually need to know where an expression ends:
[foo = bar baz]
is a message send, whereas
[foo = bar + baz]
is a lambda-introducer. Handle this by parsing the expression eagerly, and
replacing it with an annotation token. By chance, we use the *exact same*
parsing rules in both cases (except that we need to assume we're inside a
message send for the parse, to turn off various forms of inapplicable
error recovery).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182432 91177308-0d34-0410-b5e6-96231b3b80d8
common function. The C++1y contextual implicit conversion rules themselves are
not yet implemented, however.
This also fixes a subtle bug where template instantiation context notes were
dropped for diagnostics coming from conversions for integral constant
expressions -- we were implicitly slicing a SemaDiagnosticBuilder into a
DiagnosticBuilder when producing these diagnostics, and losing their context
notes in the process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182406 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch, clang-format will try to keep the cursor at the
original code position in editor integrations (implemented for emacs and
vim). This means, after formatting, clang-format will try to keep the
cursor on the same character of the same token.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182373 91177308-0d34-0410-b5e6-96231b3b80d8
attach, rather than merging all comments on the declaration chain. This gives a
more faithful dump, and has the side benefit of unbreaking uses of dump() from
within AST deserialization (where the redeclaration chain may not be sane).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182350 91177308-0d34-0410-b5e6-96231b3b80d8
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182329 91177308-0d34-0410-b5e6-96231b3b80d8
AsmPrinter::EmitLinkage() does not handle dllimport linkage. The LLVM
verifier should also be fixed to reject this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182320 91177308-0d34-0410-b5e6-96231b3b80d8
protocols that declare the same property of incompatible
types, issue a warning when class implementation synthesizes
the property. // rdar://13075400
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182316 91177308-0d34-0410-b5e6-96231b3b80d8
While the C++ standard requires that this lookup take place only at the
definition point of a virtual destructor (C++11 [class.dtor]p12), the
Microsoft ABI may require the compiler to emit a deleting destructor
for any virtual destructor declared in the TU, including ones without
a body, requiring an operator delete() lookup for every virtual
destructor declaration. The result of the lookup should be the same
no matter which declaration is used (except in weird corner cases).
This change will cause us to reject some valid TUs in Microsoft ABI
mode, e.g.:
struct A {
void operator delete(void *);
};
struct B {
void operator delete(void *);
};
struct C : A, B {
virtual ~C();
};
As Richard points out, every virtual function declared in a TU
(including this virtual destructor) is odr-used, so it must be defined
in any program which declares it, or the program is ill formed, no
diagnostic required. Because we know that any definition of this
destructor will cause the lookup to fail, the compiler can choose to
issue a diagnostic here.
Differential Revision: http://llvm-reviews.chandlerc.com/D822
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182270 91177308-0d34-0410-b5e6-96231b3b80d8
selectany only applies to externally visible global variables. It has
the effect of making the data weak_odr.
The MSDN docs suggest that unused definitions can only be dropped at
linktime, so Clang uses weak instead of linkonce. MSVC optimizes away
references to constant selectany data, so it must assume that there is
only one definition, hence weak_odr.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D814
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182266 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )
This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).
This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182231 91177308-0d34-0410-b5e6-96231b3b80d8
imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math,
regardless of in which order and regardless of the tool chain default.
I've fixed this to follow the logic:
1) If the last dominating flag is -fno-math-errno, -ffast-math, or
-Ofast, then do not use math-errno.
2) If the last dominating flag is an explicit -fmath-errno, do use
math-errno.
3) Otherwise, use the toolchain default.
This, for example, allows the flag sequence
'-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or
'-fno-math-errno' to preserve the toolchain default. Most notably, this
should prevent users trying to disable fast-math optimizations on Darwin
and BSD platforms from simultaneously enabling (pointless) -fmath-errno.
I've enhanced the tests (after more reorganization) to cover this and
other weird permutations of flags and targets.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182203 91177308-0d34-0410-b5e6-96231b3b80d8
Constructs like PseudoObjectExpr, where an expression can appear more than
once in the AST, use OpaqueValueExprs to guard against inadvertent
re-processing of the shared expression during AST traversal. The most
common form of this is to share expressions between the syntactic
"as-written" form of, say, an Objective-C property access 'obj.prop', and
the underlying "semantic" form '[obj prop]'.
However, some constructs can produce OpaqueValueExprs that don't appear in
the syntactic form at all; in these cases the ParentMap wasn't ever traversing
the children of these expressions. This patch fixes that by checking to see
if an OpaqueValueExpr's child has ever been traversed before. There's also a
bit of reset logic when visiting a PseudoObjectExpr to handle the case of
updating the ParentMap, which some external clients depend on.
This still isn't exactly the right fix because we probably want the parent
of the OpaqueValueExpr itself to be its location in the syntactic form if
it's syntactic and the PseudoObjectExpr or BinaryConditionalOperator itself
if it's semantic. Whe I originally wrote the code to do this, I didn't realize
that OpaqueValueExprs themselves are shared in the AST, not just their source
expressions. This patch doesn't change the existing behavior so as not to
break anything inadvertently relying on it; we'll come back to this later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182187 91177308-0d34-0410-b5e6-96231b3b80d8
Ted and I spent a long time discussing this today and found out that neither
the existing code nor the new code was doing what either of us thought it
was, which is never good. The good news is we found a much simpler way to
fix the motivating test case (an ObjCSubscriptExpr).
This reverts r182083, but pieces of it will come back in subsequent commits.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182185 91177308-0d34-0410-b5e6-96231b3b80d8
assert_exclusive_lock and assert_shared_lock. These attributes are used to
mark functions that dynamically check (i.e. assert) that a lock is held.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182170 91177308-0d34-0410-b5e6-96231b3b80d8
is used for Objective-C++’s dictionary subscripting. This is done by filtering
out all placeholder types before check on lowering of the
common expression is done. // rdar://1374918.
Reviewed by John McCall.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182120 91177308-0d34-0410-b5e6-96231b3b80d8
This shares the warn_attribute_unused diagnostic and reduces the
indentation level. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182096 91177308-0d34-0410-b5e6-96231b3b80d8
This optimizes some spurious edges resulting from PseudoObjectExprs.
This required far more changes than I anticipated. The current
ParentMap does not record any hierarchy information between
a PseudoObjectExpr and its *semantic* expressions that may be
wrapped in OpaqueValueExprs, which are the expressions actually
laid out in the CFG. This means the arrow pruning logic could
not map from an expression to its containing PseudoObjectExprs.
To solve this, this patch adds a variant of ParentMap that
returns the "semantic" parentage of expressions (essentially
as they are viewed by the CFG). This alternate ParentMap is then
used by the arrow reducing logic to identify edges into pseudo
object expressions, and then eliminate them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182083 91177308-0d34-0410-b5e6-96231b3b80d8
Basically, the new rule is: The opening "{" always has to be on the
same line as the first element if the braced list is nested
(e.g. in another braced list or in a function).
The solution that clang-format produces almost always adheres to this
rule anyway and this makes clang-format significantly faster for larger
lists. Added a test cases for the only exception I could find
(which doesn't seem to be very important at first sight).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182082 91177308-0d34-0410-b5e6-96231b3b80d8
This means adding an extra edge from the 'if' to the condition,
which aesthetically looks more pleasing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182079 91177308-0d34-0410-b5e6-96231b3b80d8
instantiate the inherited constructor template and mark that as the constructor
which the instantiated specialization is inheriting. This fixes a
crash-on-valid when trying to compute the exception specification of a
specialization of the inheriting constructor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182072 91177308-0d34-0410-b5e6-96231b3b80d8
The analyzer can't see the reference count for shared_ptr, so it doesn't
know whether a given destruction is going to delete the referenced object.
This leads to spurious leak and use-after-free warnings.
For now, just ban destructors named '~shared_ptr', which catches
std::shared_ptr, std::tr1::shared_ptr, and boost::shared_ptr.
PR15987
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182071 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we’ve used the last location of the analyzer issue path as the location of the
report. This might not provide the best user experience, when one analyzer a source
file and the issue appears in the header. Introduce an option to use the last location
of the path that is in the main source file as the report location.
New option can be enabled with -analyzer-config report-in-main-source-file=true.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182058 91177308-0d34-0410-b5e6-96231b3b80d8
synthesize a property getter method that overrides
a method definition named 'retain' and the like.
Fixes // rdar://13885083
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182039 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that several implementations go through the trouble of
setting up a SourceManager and Lexer and abstracting this into a
function makes usage easier.
Also abstracts SourceManager-independent ranges out of
tooling::Refactoring and provides a convenience function to create them
from line ranges.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181997 91177308-0d34-0410-b5e6-96231b3b80d8
a FieldDecl from it, and propagate both into the closure type and the
LambdaExpr.
You can't do much useful with them yet -- you can't use them within the body
of the lambda, because we don't have a representation for "the this of the
lambda, not the this of the enclosing context". We also don't have support or a
representation for a nested capture of an init-capture yet, which was intended
to work despite not being allowed by the current standard wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181985 91177308-0d34-0410-b5e6-96231b3b80d8
In the case of inline functions, we have to special case local types
when they are used as template arguments to make sure the template
instantiations are still uniqued in case the function itself is inlined.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181981 91177308-0d34-0410-b5e6-96231b3b80d8
prevents further errors and some overflows in size calculations.
One overflow was previously triggering an assert.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181970 91177308-0d34-0410-b5e6-96231b3b80d8
It used to point to the first call that caused the landing pad to
be generated.
rdar://problem/13888152
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181958 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r181393 (git 3923d6a87f).
This seems to be emitting too much extra debug info for two (known)
reasons:
* full class definitions are emitted when only declarations are expected
* unused using declarations still produce DW_TAG_imported_declarations
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181947 91177308-0d34-0410-b5e6-96231b3b80d8
This class is a StmtVisitor that distinguishes between block-level and
non-block-level statements in a CFG. However, it does so using a hard-coded
idea of which statements might be block-level, which probably isn't accurate
anymore. The only implementer of the CFGStmtVisitor hierarchy was the
analyzer's DeadStoresChecker, and the analyzer creates a linearized CFG
anyway (every non-trivial statement is a block-level statement).
This also allows us to remove the block-expr map ("BlkExprMap"), which
mapped statements to positions in the CFG. Apart from having a helper type
that really should have just been Optional<unsigned>, it was only being
used to ask /if/ a particular expression was block-level, for traversal
purposes in CFGStmtVisitor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181945 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
namespace abc { class SomeClass; }
namespace def { void someFunction() {} }
After:
namespace abc {
class Def;
}
namespace def {
void someFunction() {}
}
Rationale:
a) Having anything other than forward declaration on the same line
as a namespace looks confusing.
b) Formatting namespace-forward-declaration-combinations different
from other stuff is inconsistent.
c) Wasting vertical space close to such forward declarations really
does not affect readability.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181887 91177308-0d34-0410-b5e6-96231b3b80d8
This commit improves Clang's diagnostics for string initialization.
Where it would previously say:
/tmp/a.c:3:9: error: array initializer must be an initializer list
wchar_t s[] = "Hi";
^
/tmp/a.c:4:6: error: array initializer must be an initializer list or string literal
char t[] = L"Hi";
^
It will now say
/tmp/a.c:3:9: error: initializing wide char array with non-wide string literal
wchar_t s[] = "Hi";
^
/tmp/a.c:4:6: error: initializing char array with wide string literal
char t[] = L"Hi";
^
As a bonus, it also fixes the fact that Clang would previously reject
this valid C11 code:
char16_t s[] = u"hi";
char32_t t[] = U"hi";
because it would only recognize the built-in types for char16_t and
char32_t, which do not exist in C.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181880 91177308-0d34-0410-b5e6-96231b3b80d8
We only ever implemented one and that one is not actually all that
helpful (e.g. gets incorrectly triggered by macros).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181871 91177308-0d34-0410-b5e6-96231b3b80d8
The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.
Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After: #define DEREF_AND_CALL_F(parameter) f(*parameter)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181870 91177308-0d34-0410-b5e6-96231b3b80d8
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181869 91177308-0d34-0410-b5e6-96231b3b80d8
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181847 91177308-0d34-0410-b5e6-96231b3b80d8
ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181832 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the complexity of this patch is figuring out which types get the
qualifier and which don't. If we implement __ptr32/64, then we should
check the qualifier instead of assuming all pointers are 64-bit.
This fixes PR13792.
Patch by Warren Hunt!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181825 91177308-0d34-0410-b5e6-96231b3b80d8
Current gcc's produce an error if __clear_cache is anything but
__clear_cache(char *a, char *b);
It looks like we had just implemented a gcc bug that is now fixed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181784 91177308-0d34-0410-b5e6-96231b3b80d8
We have been assuming that CharSourceRange::getTokenRange() by itself
expands a range until the end of a token, but in fact it only sets
IsTokenRange to true. Thus, we have so far only considered the first
character of the last token to belong to an unwrapped line. This
did not really manifest in symptoms as all edit integrations
expand ranges to fully lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181778 91177308-0d34-0410-b5e6-96231b3b80d8
Before (in styles that allow it), clang-format would not merge an
if statement onto a single line, if only the second line was format
(e.g. in an editor integration):
if (a)
return; // clang-format invoked on this line.
With this patch, this gets properly merged to:
if (a) return; // ...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181770 91177308-0d34-0410-b5e6-96231b3b80d8
This library supports all the features of the compile-time based ASTMatcher
library, but allows the user to specify and construct the matchers at runtime.
It contains the following modules:
- A variant type, to be used by the matcher factory.
- A registry, where the matchers are indexed by name and have a factory method
with a generic signature.
- A simple matcher expression parser, that can be used to convert a matcher
expression string into actual matchers that can be used with the AST at
runtime.
Many features where omitted from this first revision to simplify this code
review. The main ideas are still represented in this change and it already has
support working use cases.
Things that are missing:
- Support for polymorphic matchers. These requires supporting code in the
registry, the marshallers and the variant type.
- Support for numbers, char and bool arguments to the matchers. This requires
supporting code in the parser and the variant type.
- A command line program putting everything together and providing an already
functional tool.
Patch by Samuel Benzaquen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181768 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes indentation where there are for example multiple closing
parentheses after a string literal, and where those parentheses
run over the end of the line.
During testing this revealed a bug in the implementation of
breakProtrudingToken: we don't want to change the state if we didn't
actually do anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181767 91177308-0d34-0410-b5e6-96231b3b80d8
This matches gcc's behaviour. The patch also explicitly parses the version so
that this keeps working when we add support for v8.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181750 91177308-0d34-0410-b5e6-96231b3b80d8
We might benefit from API refactoring here (why pass in a value that's
derived from another parameter?) but this is the immediate issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181747 91177308-0d34-0410-b5e6-96231b3b80d8
This is safe given how the pre-v6 atomic ops funcions in libgcc are
implemented.
This fixes pr15429.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181728 91177308-0d34-0410-b5e6-96231b3b80d8
recovery form duplicate method definition error thus
preventing doc parsing to loop trying to find comment
for the invalid redefinition in a previous declaration.
// rdar://13836387
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181710 91177308-0d34-0410-b5e6-96231b3b80d8
In r181677 I removed this llvm_unreachable and it introduced a gcc
warning. Add it back.
Thanks to Patrik Hägglund for noticing it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181704 91177308-0d34-0410-b5e6-96231b3b80d8
We now support "Linux" and "Stroustrup" brace breaking styles, which
gets us one step closer to support formatting WebKit, KDE & Linux code.
Linux brace breaking style:
namespace a
{
class A
{
void f()
{
if (x) {
f();
} else {
g();
}
}
}
}
Stroustrup brace breaking style:
namespace a {
class A {
void f()
{
if (x) {
f();
} else {
g();
}
}
}
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181700 91177308-0d34-0410-b5e6-96231b3b80d8
Fake parentheses (i.e. emulated parentheses used to correctly handle
binary expressions) used to prevent the optimization implemented in
r180264.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181692 91177308-0d34-0410-b5e6-96231b3b80d8
This seems to be the vastly more common case. If we find enough
examples to the contrary, we can make it smarter.
Before: #define MACRO void f(int * a)
After: #define MACRO void f(int *a)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181687 91177308-0d34-0410-b5e6-96231b3b80d8
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181677 91177308-0d34-0410-b5e6-96231b3b80d8
type returns a lambda defined within itself. The computation of linkage for the
function looked at the linkage of the lambda, and vice versa.
This is solved by not checking whether an 'auto' in a function return type
deduces to a type with unique external linkage. We don't need this check,
because the type deduced for 'auto' doesn't affect whether two
otherwise-identical declarations would name different functions, so we don't
need to give an ostensibly external-linkage function internal linkage for this
reason. (We also don't need unique-external linkage in C++11 onwards at all,
but that's not implemented yet.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181675 91177308-0d34-0410-b5e6-96231b3b80d8
inefficient; we perform a linear scan of switch labels to find the one matching
the condition, and then walk the body looking for that label. Both parts should
be straightforward to optimize.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181671 91177308-0d34-0410-b5e6-96231b3b80d8
Adding attributes to a uniqued set has become expensive, don't do it more often
than necessary. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181662 91177308-0d34-0410-b5e6-96231b3b80d8
we loaded from PCH, if we're building another PCH, create an update record to
patch the return type of the earlier declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181659 91177308-0d34-0410-b5e6-96231b3b80d8
We could support the GCC extension DW_TAG_GNU_template_parameter_pack if
we're feeling adventurous, at some point - but I don't think GDB's doing
anything useful with it yet anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181644 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes people hack on their system headers. In such cases, they'll
need to delete their module cache, but may not know where it is. Add a
note to show them where it is.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181638 91177308-0d34-0410-b5e6-96231b3b80d8
* Provide DW_TAG_template_value_parameter for pointers, function
pointers, member pointers, and member function pointers (still missing
support for template template parameters which GCC encodes as a
DW_TAG_GNU_template_template_param)
* Provide values for all but the (member & non-member) function pointer case.
Simple constant integer values for member pointers (offset within the
object) and address for the value pointer case. GCC doesn't provide a
value for the member function pointer case so I'm not sure how, if at
all, GDB supports encoding that. & non-member function pointers should
follow shortly in a subsequent patch.
* Null pointer value encodings of all of these types, including
correctly encoding null data member pointers as -1.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181634 91177308-0d34-0410-b5e6-96231b3b80d8
In most cases it is, by just looking at the name. Also, this check prevents the heuristic from working in strange user settings.
radar://13839692
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181615 91177308-0d34-0410-b5e6-96231b3b80d8
Consider this example:
char *p = malloc(sizeof(char));
systemFunction(&p);
free(p);
In this case, when we call systemFunction, we know (because it's a system
function) that it won't free 'p'. However, we /don't/ know whether or not
it will /change/ 'p', so the analyzer is forced to invalidate 'p', wiping
out any bindings it contains. But now the malloc'd region looks like a
leak, since there are no more bindings pointing to it, and we'll get a
spurious leak warning.
The fix for this is to notice when something is becoming inaccessible due
to invalidation (i.e. an imperfect model, as opposed to being explicitly
overwritten) and stop tracking it at that point. Currently, the best way
to determine this for a call is the "indirect escape" pointer-escape kind.
In practice, all the patch does is take the "system functions don't free
memory" special case and limit it to direct parameters, i.e. just the
arguments to a call and not other regions accessible to them. This is a
conservative change that should only cause us to escape regions more
eagerly, which means fewer leak warnings.
This isn't perfect for several reasons, the main one being that this
example is treated the same as the one above:
char **p = malloc(sizeof(char *));
systemFunction(p + 1);
// leak
Currently, "addresses accessible by offsets of the starting region" and
"addresses accessible through bindings of the starting region" are both
considered "indirect" regions, hence this uniform treatment.
Another issue is our longstanding problem of not distinguishing const and
non-const bindings; if in the first example systemFunction's parameter were
a char * const *, we should know that the function will not overwrite 'p',
and thus we can safely report the leak.
<rdar://problem/13758386>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181607 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise (when indenting from the wrapped -> or .), this looks
like a confusing indent.
Before:
aaaaaaa //
.aaaaaaa( //
aaaaaaa);
After:
aaaaaaa //
.aaaaaaa( //
aaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181595 91177308-0d34-0410-b5e6-96231b3b80d8
Thereby, the macro is consistently formatted (including the trailing
escaped newlines) even if clang-format is invoked only on single lines
of the macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181590 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Adds actual config file reading to the clang-format utility.
Configuration file name is .clang-format. It is looked up for each input file
in its parent directories starting from immediate one. First found .clang-format
file is used. When using standard input, .clang-format is searched starting from
the current directory.
Added -dump-config option to easily create configuration files.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, jordan_rose, kimgr
Differential Revision: http://llvm-reviews.chandlerc.com/D758
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181589 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC provides __wchar_t. This is the same as the built-in wchar_t type
from C++, but it is also available with -fno-wchar and in C.
The commit changes ASTContext to have two different types for this:
- WCharTy is the built-in type used for wchar_t in C++ and __wchar_t.
- WideCharTy is the type of a wide character literal. In C++ this is
the same as WCharTy, and in C it is an integer type compatible with
the type in <stddef.h>.
This fixes PR15815.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181587 91177308-0d34-0410-b5e6-96231b3b80d8
Before, the actual operator of an overloaded operator declaration was
handled as a binary operator an thus, clang-format could not find valid
formattings for many examples, e.g.:
template <typename AAAAAAA, typename BBBBBBB>
AAAAAAA operator/(const AAAAAAA &a, BBBBBBB &b);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181585 91177308-0d34-0410-b5e6-96231b3b80d8
substitute 'void' into the return type rather than replacing it with 'void', so
that we maintain the 'auto' type sugar.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181584 91177308-0d34-0410-b5e6-96231b3b80d8
Now tests should pass. The previous error was caused by a misplaced backing
array for MutableArrayRef that I introduced.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181570 91177308-0d34-0410-b5e6-96231b3b80d8
for C++ constructors.
If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.
rdar://problem/13116508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181561 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes several (7 out of 16) cases of PR14492 in the GDB 7.5 test
suite. It seems GDB was bailing out whenever it had even the slightest
problem with the template argument list (& I assume it didn't like
seeing template value parameters that were just simple names - perhaps
assuming that lone names must be types, not values)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181556 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This only supports converting along non-virtual inheritance paths by
changing the field offset or the non-virtual base adjustment.
This implements three kinds of conversions:
- codegen for Value conversions
- Constant emission for APValue
- Constant folding for CastExprs
In almost all constant initialization settings
EmitMemberPointer(APValue) is called, except when the expression
contains a reinterpret cast.
reinterpret casts end up being a big corner case because the null value
changes between different kinds of member pointers.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D741
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181543 91177308-0d34-0410-b5e6-96231b3b80d8
This was added, untested (though the relevant crash was tested), in
r128725/PR9600. Removing it doesn't cause failures & nothing I can
imagine could cause this check to ever return 'true' (we should never be
dealing with dependent types here). The subsequent change to check
"isIncompleteType" (r128855/PR9608) makes a lot more sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181542 91177308-0d34-0410-b5e6-96231b3b80d8
EmitCapturedStmt creates a captured struct containing all of the captured
variables, and then emits a call to the outlined function. This is similar in
principle to EmitBlockLiteral.
GenerateCapturedFunction actually produces the outlined function. It is based
on GenerateBlockFunction, but is much simpler. The function type is determined
by the parameters that are in the CapturedDecl.
Some changes have been added to this patch that were reviewed as part of the
serialization patch and moving the parameters to the captured decl.
Differential Revision: http://llvm-reviews.chandlerc.com/D640
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181536 91177308-0d34-0410-b5e6-96231b3b80d8
'commands' will not go through typo fixit logic,
preserving the old behavior (no typo, no diagnostics).
// rdar://12381408
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181521 91177308-0d34-0410-b5e6-96231b3b80d8
object x, x's subobjects can be constructed by constexpr constructor even if
they are of non-literal type, and can be read and written even though they're
not members of a constexpr object or temporary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181506 91177308-0d34-0410-b5e6-96231b3b80d8
clang would omit 'C' for 'copy' properties and '&' for 'retain' properties if
the property was also 'readonly'. Fix this, which makes clang match gcc4.2's
behavior.
Fixes PR15928.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181491 91177308-0d34-0410-b5e6-96231b3b80d8
This made sense in pre-module era, before merging of HeaderFileInfos was introduced.
Final part of rdar://13840148.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181490 91177308-0d34-0410-b5e6-96231b3b80d8
After r180934 we may initiate module map parsing for modules not related to the module what we are building,
make sure we ignore the header file info of headers from such modules.
First part of rdar://13840148
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181489 91177308-0d34-0410-b5e6-96231b3b80d8
Manuel Klimek
Daniel Jasper
Sergey Matveev
Nico Weber
Rafael Espindola
Duncan Sands
Argyrios Kyrtzidis
Jordan Rose
Michael J. Spencer
David Blaikie
Diego Novillo
Chad Rosier
Alexander Kornienko
Aaron Ballman
Evgeniy Stepanov
Richard Smith
Bill Wendling
Benjamin Kramer
Ted Kremenek
Adrian Prantl
Pete Cooper
Reid Kleckner
Anna Zaks
Fariborz Jahanian
Eric Christopher
DeLesley Hutchins
Peter Collingbourne
Douglas Gregor
Jakob Stoklund Olesen
Chandler Carruth
Serge Pavlov
Dmitri Gribenko
David Fang
Enea Zaffanella
Hans Wennborg
Richard Trieu
Samuel Benzaquen
Alexey Bataev
Simon Atanasyan
Ben Langmuir