is issused for on overriding 'readwrite'
property which is not auto-synthesized.
Buttom line is that if hueristics determine
that there will be a user implemented setter,
no warning will be issued. // rdar://13388503
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177662 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
1. When splitting one-line block comment, use indentation and *s.
2. Remove trailing whitespace from all lines of a comment, not only the ones being splitted.
3. Add backslashes for all lines if a comment is used insed a preprocessor directive.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D557
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177635 91177308-0d34-0410-b5e6-96231b3b80d8
* libclang_rt-san-* is sanitizer_common, and is linked in only if no other
sanitizer runtime is present.
* libclang_rt-ubsan-* is the piece of the runtime which doesn't depend on
a C++ ABI library, and is always linked in.
* libclang_rt-ubsan_cxx-* is the piece of the runtime which depends on a
C++ ABI library, and is only linked in when linking a C++ binary.
This change also switches us to using -whole-archive for the ubsan runtime
(which is made possible by the above split), and switches us to only linking
the sanitizer runtime into the main binary and not into DSOs (which is made
possible by using -whole-archive).
The motivation for this is to only link a single copy of sanitizer_common
into any binary. This is becoming important now because we want to share
more state between multiple sanitizers in the same process (for instance,
we want a single shared output mutex).
The Darwin ubsan runtime is unchanged; because we use a DSO there, we don't
need this complexity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177605 91177308-0d34-0410-b5e6-96231b3b80d8
* Clarify what MacroInfo::isBuiltinMacro means, as it really means something
more like "isMagicalMacro" or "requiresProcessingBeforeExpansion" -- the
macros defined in "<built-in>" are not considered built-in by this function;
* Escape __LINE__ as \__LINE__ in Doxygen comments so that the underscores
don't get replaced by *bold* output;
* Turn comments in MacroInfo.cpp into non-Doxygen comments, so that they
don't result in duplicated/badly formatted Doxygen output;
* Clean up a bunch of \brief formatting, and add a \file comment for
MacroInfo.h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177581 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes some mistaken condition logic in RegionStore that caused
global variables to be invalidated when /any/ region was invalidated,
rather than only as part of opaque function calls. This was only
being used by CStringChecker, and so users will now see that strcpy()
and friends do not invalidate global variables.
Also, add a test case we don't handle properly: explicitly-assigned
global variables aren't being invalidated by opaque calls. This is
being tracked by <rdar://problem/13464044>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177572 91177308-0d34-0410-b5e6-96231b3b80d8
Due to improper modelling of copy constructors (specifically, their
const reference arguments), we were producing spurious leak warnings
for allocated memory stored in structs. In order to silence this, we
decided to consider storing into a struct to be the same as escaping.
However, the previous commit has fixed this issue and we can now properly
distinguish leaked memory that happens to be in a struct from a buffer
that escapes within a struct wrapper.
Originally applied in r161511, reverted in r174468.
<rdar://problem/12945937>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177571 91177308-0d34-0410-b5e6-96231b3b80d8
In this case, the value of 'x' may be changed after the call to indirectAccess:
struct Wrapper {
int *ptr;
};
void indirectAccess(const Wrapper &w);
void test() {
int x = 42;
Wrapper w = { x };
clang_analyzer_eval(x == 42); // TRUE
indirectAccess(w);
clang_analyzer_eval(x == 42); // UNKNOWN
}
This is important for modelling return-by-value objects in C++, to show
that the contents of the struct are escaping in the return copy-constructor.
<rdar://problem/13239826>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177570 91177308-0d34-0410-b5e6-96231b3b80d8
This is a bit of old code trying to deal with the fact that functions that
take pointers often use them to access an entire array via pointer
arithmetic. However, RegionStore already conservatively assumes you can use
pointer arithmetic to access any part of a region.
Some day we may want to go back to handling this specifically for calls,
but we can do that in the future.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177569 91177308-0d34-0410-b5e6-96231b3b80d8
I am not sure how much we can improve for
when a randon ObjC keyword is thrown into the
ivar decl. block. // rdar://6854840
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177553 91177308-0d34-0410-b5e6-96231b3b80d8
For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.
We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.
Updated from r177211.
rdar://12818789
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177541 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format can't do anything useful, so it should leave the remainder
of the line unchanged, but it should not assert/segfault.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177530 91177308-0d34-0410-b5e6-96231b3b80d8
Before (when only reformatting "int b"):
int a; // comment
// comment
int b;
After:
int a; // comment
// comment
int b;
This also fixes llvm.org/PR15433.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177524 91177308-0d34-0410-b5e6-96231b3b80d8
This seems to be generally more desired.
Before:
if (aaaaaaaa &&
bbbbbbbb >
cccccccc) {}
After:
if (aaaaaaaa &&
bbbbbbbb >
cccccccc) {}
Also: Some formatting cleanup on clang-format's files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177514 91177308-0d34-0410-b5e6-96231b3b80d8
We were checking "Arch == llvm::Triple::x86_64 || Arch
== llvm::Triple::x86_64", but the rhs should actually check for
powerpc64.
Found while experimenting with a potential new Clang warning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177496 91177308-0d34-0410-b5e6-96231b3b80d8
Each toolchain has a set of tools, but they are all of known types. It can
have a linker, an assembler, a "clang" (compile, analyze, ...) a non-clang
compiler, etc.
Instead of keeping a map, just have member variable for each type of tool.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177479 91177308-0d34-0410-b5e6-96231b3b80d8
emit function names in .gcda files by default, and the flag turns that off!
Rename the flag to make it match what it actually does. This keeps the default
format compatible with gcc 4.2.
Also add a test for this flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177475 91177308-0d34-0410-b5e6-96231b3b80d8
This code was changed in r158376 to get template argument source info
for better diagnostics, but the current code asserts for any kind of
unsupported template argument before it can issue a diagnostic. This change
goes back to the Itanium implementation of isTemplate() and puts the argument
index into the diagnostic instead of a source location.
Review URL: http://llvm-reviews.chandlerc.com/D553
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177471 91177308-0d34-0410-b5e6-96231b3b80d8
is enabled. Also add a new -test-coverage cc1 flag which makes testing coverage
possible and add our first clang-side coverage test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177470 91177308-0d34-0410-b5e6-96231b3b80d8
With the assurance that the trimmed graph does not contain cycles,
this patch is safe (with a few tweaks), and provides the performance
boost it was intended to.
Part of performance work for <rdar://problem/13433687>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177469 91177308-0d34-0410-b5e6-96231b3b80d8
Having a trimmed graph with no cycles (a DAG) is much more convenient for
trying to find shortest paths, which is exactly what BugReporter needs to do.
Part of the performance work for <rdar://problem/13433687>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177468 91177308-0d34-0410-b5e6-96231b3b80d8
Configuration macros are macros that are intended to alter how a
module works, such that we need to build different module variants
for different values of these macros. A module can declare its
configuration macros, in which case we will complain if the definition
of a configation macro on the command line (or lack thereof) differs
from the current preprocessor state at the point where the module is
imported. This should eliminate some surprises when enabling modules,
because "#define CONFIG_MACRO ..." followed by "#include
<module/header.h>" would silently ignore the CONFIG_MACRO setting. At
least it will no longer be silent about it.
Configuration macros are eventually intended to help reduce the number
of module variants that need to be built. When the list of
configuration macros for a module is exhaustive, we only need to
consider the settings for those macros when building/finding the
module, which can help isolate modules for various project-specific -D
flags that should never affect how modules are build (but currently do).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177466 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a crash when analyzing LLVM that was exposed by r177220 (modeling of
trivial copy/move assignment operators).
When we look up a lazy binding for “Builder”, we see the direct binding of Loc at offset 0.
Previously, we believed the binding, which led to a crash. Now, we do not believe it as
the types do not match.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177453 91177308-0d34-0410-b5e6-96231b3b80d8
The whole reason we were doing a BFS in the first place is because an
ExplodedGraph can have cycles. Unfortunately, my removeErrorNode "update"
doesn't work at all if there are cycles.
I'd still like to be able to avoid doing the BFS every time, but I'll come
back to it later.
This reverts r177353 / 481fa5071c203bc8ba4f88d929780f8d0f8837ba.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177448 91177308-0d34-0410-b5e6-96231b3b80d8
closing rbrace is missing in an ObjC class declaration.
Can do beter than this, but it involves addition of
overhead which will be present in correct code.
// rdar://6854840
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177435 91177308-0d34-0410-b5e6-96231b3b80d8
If this should not happen, we should have an assert.
If it should happen, we should have a test and remove the comment.
In no case should we have this self inconsistent code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177399 91177308-0d34-0410-b5e6-96231b3b80d8
The general pattern now is that Foobar::constructTool only creates tools
defined in the tools::foobar namespace and then delegates to the parent.
The remaining duplicated code is now in the tools themselves.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177368 91177308-0d34-0410-b5e6-96231b3b80d8
The global module index was querying the file manager for each of the
module files it knows about at load time, to prune out any out-of-date
information. The file manager would then cache the results of the
stat() falls used to find that module file.
Later, the same translation unit could end up trying to import one of the
module files that had previously been ignored by the module cache, but
after some other Clang instance rebuilt the module file to bring it
up-to-date. The stale stat() results in the file manager would
trigger a second rebuild of the already-up-to-date module, causing
failures down the line.
The global module index now lazily resolves its module file references
to actual AST reader module files only after the module file has been
loaded, eliminating the stat-caching race. Moreover, the AST reader
can communicate to its caller that a module file is missing (rather
than simply being out-of-date), allowing us to simplify the
module-loading logic and allowing the compiler to recover if a
dependent module file ends up getting deleted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177367 91177308-0d34-0410-b5e6-96231b3b80d8
it wasn't taking into account that the float should be truncated *before* the
range check happens. Thus (unsigned)-0.99 and (unsigned char)255.9 have defined
behavior and should not be trapped.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177362 91177308-0d34-0410-b5e6-96231b3b80d8
Splitting the graph trimming and the path-finding (r177216) already
recovered quite a bit of performance lost to increased suppression.
We can still do better by also performing the reverse BFS up front
(needed for shortest-path-finding) and only walking the shortest path
for each report. This does mean we have to walk back up the path and
invalidate all the BFS numbers if the report turns out to be invalid,
but it's probably still faster than redoing the full BFS every time.
More performance work for <rdar://problem/13433687>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177353 91177308-0d34-0410-b5e6-96231b3b80d8
The previous implementation missed the case where the elif condition was
evaluated from the context of an #ifdef that was false causing PR15539.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177345 91177308-0d34-0410-b5e6-96231b3b80d8
I have filed http://llvm.org/bugs/show_bug.cgi?id=15538 against clang.
This code is safer anyway because "cast" assumes you really know that
it's okay to make the cast. In this case isa should not be false and
dyn_cast should not return null as far as I understand. But everything
else is valid so I did not want to revert my previous patch for attributes
mips16/nomips16 or use an llvm_unreachable here which would make a number
of our tests fail for mips.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177329 91177308-0d34-0410-b5e6-96231b3b80d8
into the pre-preprocessed file to be passed to
modern translator when compiling in no debug mode.
// rdar://13138170
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177311 91177308-0d34-0410-b5e6-96231b3b80d8
When annotating "lines" starting with ":", clang-format would segfault.
This could actually happen in valid code, e.g.
#define A :
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177283 91177308-0d34-0410-b5e6-96231b3b80d8
r175234 allowed the analyzer to model trivial copy/move constructors as
an aggregate bind. This commit extends that to trivial assignment
operators as well. Like the last commit, one of the motivating factors here
is not warning when the right-hand object is partially-initialized, which
can have legitimate uses.
<rdar://problem/13405162>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177220 91177308-0d34-0410-b5e6-96231b3b80d8
When we generate a path diagnostic for a bug report, we have to take the
full ExplodedGraph and limit it down to a single path. We do this in two
steps: "trimming", which limits the graph to all the paths that lead to
this particular bug, and "creating the report graph", which finds the
shortest path in the trimmed path to any error node.
With BugReporterVisitor false positive suppression, this becomes more
expensive: it's possible for some paths through the trimmed graph to be
invalid (i.e. likely false positives) but others to be valid. Therefore
we have to run the visitors over each path in the graph until we find one
that is valid, or until we've ruled them all out. This can become quite
expensive.
This commit separates out graph trimming from creating the report graph,
performing the first only once per bug equivalence class and the second
once per bug report. It also cleans up that portion of the code by
introducing some wrapper classes.
This seems to recover most of the performance regression described in my
last commit.
<rdar://problem/13433687>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177216 91177308-0d34-0410-b5e6-96231b3b80d8
...in favor of this typedef:
typedef llvm::DenseMap<const ExplodedNode *, const ExplodedNode *>
InterExplodedGraphMap;
Use this everywhere the previous class and typedef were used.
Took the opportunity to ArrayRef-ize ExplodedGraph::trim while I'm at it.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177215 91177308-0d34-0410-b5e6-96231b3b80d8
I removed this check in the recursion->iteration commit, but forgot that
generatePathDiagnostic may be called multiple times if there are multiple
PathDiagnosticConsumers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177214 91177308-0d34-0410-b5e6-96231b3b80d8
For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.
We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.
rdar://12818789
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177211 91177308-0d34-0410-b5e6-96231b3b80d8
When the template argument is both default and value dependent, the expression
retrieved for the default argument cannot be evaluated, thus never matching
any argument value. To get the proper value, get the template argument
from the desugared template specialization. Also, output the original
expression to provide more information about the argument mismatch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177209 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes a FIXME, improves dead symbol collection, suppresses a false positive,
which resulted from reusing the same symbol twice for simulation of 2 calls to the same function.
Fixing this lead to 2 possible false negatives in CString checker. Since the checker is still alpha and
the solution will not require revert of this commit, move the tests to a FIXME section.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177206 91177308-0d34-0410-b5e6-96231b3b80d8
I don't have a good testcase for this that does not depend on system headers.
It did not trigger with preprocessed output, and I had trouble reducing the example.
Fixes <rdar://problem/13324594>.
Thanks to Michael Greiner for reporting this issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177201 91177308-0d34-0410-b5e6-96231b3b80d8
These will be available in the current translation unit anyway, for
modules they only waste space and deserialization time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177197 91177308-0d34-0410-b5e6-96231b3b80d8
When we're building a precompiled header or module against an SDK on
Darwin, there will be a file SDKSettings.plist in the sysroot. Since
stat()'ing every system header on which a module or PCH file depends
is performance suicide, we instead stat() just SDKSettings.plist. This
hack works well on Darwin; it's unclear how we want to handle this on
other platforms. If there is a canonical file, we should use it; if
not, we either have to take the performance hit of stat()'ing system
headers repeatedly or roll the dice by not checking anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177194 91177308-0d34-0410-b5e6-96231b3b80d8
The previous generatePathDiagnostic() was intended to be tail-recursive,
restarting and trying again if a report was marked invalid. However:
(1) this leaked all the cloned visitors, which weren't being deleted, and
(2) this wasn't actually tail-recursive because some local variables had
non-trivial destructors.
This was causing us to overflow the stack on inputs with large numbers of
reports in the same equivalence class, such as sqlite3.c. Being iterative
at least prevents us from blowing out the stack, but doesn't solve the
performance issue: suppressing thousands (yes, thousands) of paths in the
same equivalence class is expensive. I'm looking into that now.
<rdar://problem/13423498>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177189 91177308-0d34-0410-b5e6-96231b3b80d8
We discovered that sqlite3.c currently has 2600 reports in a single
equivalence class; it would be good to know if this is a recent
development or what.
(For the curious, the different reports in an equivalence class represent
the same bug found along different paths. When we're suppressing false
positives, we need to go through /every/ path to make sure there isn't a
valid path to a bug. This is a flaw in our after-the-fact suppression,
made worse by the fact that that function isn't particularly optimized.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177188 91177308-0d34-0410-b5e6-96231b3b80d8
- This fast path is almost 100% effective on real code, and lets us avoid
multiple allocations of 128-bit APSInt objects in the common case.
- As with any overflow-check-skipping-code, I'd appreciate someone double
checking my logic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177183 91177308-0d34-0410-b5e6-96231b3b80d8
Information messages sent to stdout by ClangTool now only happen when the
-debug flag is set.
Error messages that used to go to stdout now go to stderr.
Author: Ariel J Bernal <ariel.j.bernal@intel.com>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177177 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r177158.
I'm blindly reverting this because it appears to be breaking numerous
buildbots. I'll reapply if it doesn't turn out to be the culprit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177165 91177308-0d34-0410-b5e6-96231b3b80d8
the balance between expected behavior and compatibility with the gdb
testsuite.
(GDB gets confused if we break an expression into multiple debug
stmts so we enable this behavior only for inlined functions. For the
full experience people can still use -gcolumn-info.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177164 91177308-0d34-0410-b5e6-96231b3b80d8
FindNodeOrInsertPos() is called 10 lines earlier already, and the function
early-returns there if the result is != 0. InsertPos isn't recomputed after
that check, so this assert is always trivially true. (And it has nothing to
do with if T is canonical or not.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177158 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format already prevented sequences like:
...
SomeParameter).someFunction(
...
as those are quite confusing. This failed on:
...
SomeParameter).someFunction(otherFunction(
...
Fixed in this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177157 91177308-0d34-0410-b5e6-96231b3b80d8
therefore references to members should not be transformed into implicit uses of
'this'. Patch by Ismail Pazarbasi!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177134 91177308-0d34-0410-b5e6-96231b3b80d8
This created 2 issues:
1) Performance issue, since typo-correction with PCH/modules is rather expensive.
2) Correctness issue, since if it managed to "correct" 'super' then bogus compiler errors would
be emitted, like this:
3.m:8:3: error: unknown type name 'super'; did you mean 'super1'?
super.x = 0;
^~~~~
super1
t3.m:5:13: note: 'super1' declared here
typedef int super1;
^
t3.m:8:8: error: expected identifier or '('
super.x = 0;
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177126 91177308-0d34-0410-b5e6-96231b3b80d8
In the test case below, the value V is not constrained to 0 in ErrorNode but it is in node N.
So we used to fail to register the Suppression visitor.
We also need to change the way we determine that the Visitor should kick in because the node N belongs to
the ExplodedGraph and might not be on the BugReporter path that the visitor sees. Instead of trying to match the node,
turn on the visitor when we see the last node in which the symbol is ‘0’.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177121 91177308-0d34-0410-b5e6-96231b3b80d8
This way the register allocator will not optimize away the debug info
for captured variables.
Fixes rdar://problem/12767564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177086 91177308-0d34-0410-b5e6-96231b3b80d8
This yields a log(#ast_nodes) worst-case improvement with matchers like
stmt(unless(hasAncestor(...))).
Also made the order of visitation for ancestor matches BFS, as the most
common use cases (for example finding the closest enclosing function
definition) rely on that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177081 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Aligns continuation lines of multi-line comments to the base
indentation level +1:
class A {
/*
* test
*/
void f() {}
};
The first revision is work in progress. The implementation is not yet complete.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D541
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177080 91177308-0d34-0410-b5e6-96231b3b80d8
The stronger binding of a string ending in :/= does not really make
sense if it is the only character.
Before:
llvm::outs() << aaaaaaaaaaaaaaaaaaaaaaaa
<< "=" << bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
After:
llvm::outs() << aaaaaaaaaaaaaaaaaaaaaaaa << "="
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177075 91177308-0d34-0410-b5e6-96231b3b80d8
template instantiation will still consider them to be definitions
if we instantiate the containing class before we get around
to parsing the friend.
This seems like a legitimate use of "late template parsed" to me,
but I'd appreciate it if someone responsible for the MS feature
would look over this.
This file already appears to access AST nodes directly, which
is arguably not kosher in the parser, but the performance of this
path matters enough that perpetuating the sin is justifiable.
Probably we ought to reconsider this policy for very simple
manipulations like this.
The reason this entire thing is necessary is that
function template instantiation plays some very gross games
in order to not associate an instantiated function template
with the class it came from unless it's a definition, and
the reason *that's* necessary is that the AST currently
cannot represent the instantiation history of individual
function template declarations, but instead tracks it in
common for the entire function template. That probably
prevents us from correctly reporting ill-formed calls to
ambiguously instantiated friend function templates.
rdar://12350696
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177003 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.
That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.
We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.
This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176999 91177308-0d34-0410-b5e6-96231b3b80d8
The back-end cannot differentiate between functions that are from a .ll file and
those generated from the front-end. We cannot then take the non-precense of
these attributes as a "false" value. Have the front-end explicitly set the value
to 'true' or 'false' depending upon what is actually set.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176985 91177308-0d34-0410-b5e6-96231b3b80d8
In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers
in order to associate the FileEntries with their modules and support implicit
module import.
Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about
the module that a header belongs to, and associate it with its module only when
there is a request for loading the header info for a particular file.
Part of rdar://13391765
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176976 91177308-0d34-0410-b5e6-96231b3b80d8
This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.
Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176975 91177308-0d34-0410-b5e6-96231b3b80d8
When BugReporter tracks C++ references involved in a null pointer violation, we
want to differentiate between a null reference and a reference to a null pointer. In the
first case, we want to track the region for the reference location; in the second, we want
to track the null pointer.
In addition, the core creates CXXTempObjectRegion to represent the location of the
C++ reference, so teach FindLastStoreBRVisitor about it.
This helps null pointer suppression to kick in.
(Patch by Anna and Jordan.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176969 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
switch (x) {
// if 1, do f()
case 1:
f();
}
After:
switch (x) {
// if 1, do f()
case 1:
f();
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176953 91177308-0d34-0410-b5e6-96231b3b80d8
Information messages sent to stdout by ClangTool now only happen when the -debug
flag is set.
Error messages that used to go to stdout now go to stderr.
Author: Ariel J Bernal <ariel.j.bernal@intel.com>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176944 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
A = new SomeType * [Length];
A = new SomeType *[Length]();
After:
A = new SomeType *[Length];
A = new SomeType *[Length]();
Small formatting cleanups with clang-format.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176936 91177308-0d34-0410-b5e6-96231b3b80d8
for existence of user setter before
issuing the warning about non-synthesizable
property. // rdar://13388503
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176906 91177308-0d34-0410-b5e6-96231b3b80d8
differentiate multiple inlined call sites on the same line
in the debug info.
Fixes rdar://problem/13036237
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176895 91177308-0d34-0410-b5e6-96231b3b80d8
-ccc-install-dir is supposed to cause the compiler to behave as-if it
were installed in the indicated location. It almost does, but misses
anything that's relying on the resource directory (libc++ header search,
in particular). The resource dir is resolved too early, before command
line args are handled.
The fix is simply to move handling of the resource dir until after we
know if a -ccc-install-dir is present.
rdar://13402696
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176894 91177308-0d34-0410-b5e6-96231b3b80d8
when property autosynthesis does not synthesize a property.
When property is declared 'readonly' in a super class and
is redeclared 'readwrite' in a subclass. When a property
autosynthesis causes it to share 'ivar' with another property.
// rdar://13388503
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176889 91177308-0d34-0410-b5e6-96231b3b80d8
extern "C" {
void test5_f() {
extern int test5_b;
}
}
static float test5_b;
This patch makes us report one for
extern "C" {
void test6_f() {
extern int test6_b;
}
}
extern "C" {
static float test6_b;
}
Not because we think the declaration would be extern C, but because of the rule:
An entity with C language linkage shall not be declared with the same name as an entity in global scope...
We were just not looking past the extern "C" to see if the decl was in global
scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176875 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a crash in
namespace {
struct X {};
}
extern "C" X test2_b;
X test2_b
before we would assign different linkages to each of the test2_b decls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176869 91177308-0d34-0410-b5e6-96231b3b80d8
Without this patch we produce an error for
extern "C" {
void f() {
extern int b;
}
}
extern "C" {
extern float b;
}
but not for
extern "C" {
void f() {
extern int b;
}
}
extern "C" {
float b;
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176867 91177308-0d34-0410-b5e6-96231b3b80d8
Driver will now error when trying to compile for V2 or V3.
Removal of V2 and V3 support will allow us to simplify the hexagon
back-end.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176859 91177308-0d34-0410-b5e6-96231b3b80d8
r176737 fixed bugreporter::trackNullOrUndefValue to find nodes for an lvalue
even if the rvalue node had already been collected. This commit extends that
to call statement nodes as well, so that if a call is contained within
implicit casts we can still track the return value.
No test case because node reclamation is extremely finicky (dependent on
how the AST and CFG are built, and then on our current reclamation rules,
and /then/ on how many nodes were generated by the analyzer core and the
current set of checkers). I consider this a low-risk change, though, and
it will only happen in cases of reclamation when the rvalue node isn't
available.
<rdar://problem/13340764>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176829 91177308-0d34-0410-b5e6-96231b3b80d8
Modules enables features such as auto-linking, and we simply do not want to
support a matrix of subtly enabled/disabled features depending on whether or
not a user is using the integrated assembler.
It isn't clear if this is the best place to do this check. For one thing,
these kind of errors are not caught by the serialized diagnostics.
Fixes <rdar://problem/13289240>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176826 91177308-0d34-0410-b5e6-96231b3b80d8
Generate forward declarations that are RAUW'd by finalize().
We thus avoid outputting the same type several times in multiple
stages of completion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176820 91177308-0d34-0410-b5e6-96231b3b80d8
handle raw string literals here. C++11 doesn't yet specify how they will
behave, but discussion on core suggests that we should just strip off
everything but the r-char-sequence.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176779 91177308-0d34-0410-b5e6-96231b3b80d8
The visitor used to assume that the value it’s tracking is null in the first node it examines. This is not true.
If we are registering the Suppress Inlined Defensive checks visitor while traversing in another visitor
(such as FindlastStoreVisitor). When we restart with the IDC visitor, the invariance of the visitor does
not hold since the symbol we are tracking no longer exists at that point.
I had to pass the ErrorNode when creating the IDC visitor, because, in some cases, node N is
neither the error node nor will be visible along the path (we had not finalized the path at that point
and are dealing with ExplodedGraph.)
We should revisit the other visitors which might not be aware that they might get nodes, which are
later in path than the trigger point.
This suppresses a number of inline defensive checks in JavaScriptCore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176756 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, MallocChecker's pointer escape check and its post-call state
update for Objective-C method calls had a fair amount duplicated logic
and not-entirely-consistent checks. This commit restructures all this to
be more consistent and possibly allow us to be more aggressive in warning
about double-frees.
New policy (applies to system header methods only):
(1) If this is a method we know about, model it as taking/holding ownership
of the passed-in buffer.
(1a) ...unless there's a "freeWhenDone:" parameter with a zero (NO) value.
(2) If there's a "freeWhenDone:" parameter (but it's not a method we know
about), treat the buffer as escaping if the value is non-zero (YES) and
non-escaping if it's zero (NO).
(3) If the first selector piece ends with "NoCopy" (but it's not a method we
know about and there's no "freeWhenDone:" parameter), treat the buffer
as escaping.
The reason that (2) and (3) don't explicitly model the ownership transfer is
because we can't be sure that they will actually free the memory using free(),
and we wouldn't want to emit a spurious "mismatched allocator" warning
(coming in Anton's upcoming patch). In the future, we may have an idea of a
"generic deallocation", i.e. we assume that the deallocator is correct but
still continue tracking the region so that we can warn about double-frees.
Patch by Anton Yartsev, with modifications from me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176744 91177308-0d34-0410-b5e6-96231b3b80d8
so that it looks through certain syntactic forms and applies
even if normal inference would have succeeded.
There is potential for source incompatibility from this
change, but overall we feel that it produces a much
cleaner and more defensible result, and the block
compatibility rules should curb a lot of the potential
for annoyance.
rdar://13200889
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176743 91177308-0d34-0410-b5e6-96231b3b80d8
r176010 introduced the notion of "interesting" lvalue expressions, whose
nodes are guaranteed never to be reclaimed by the ExplodedGraph. This was
used in bugreporter::trackNullOrUndefValue to find the region that contains
the null or undef value being tracked.
However, the /rvalue/ nodes (i.e. the loads from these lvalues that produce
a null or undef value) /are/ still being reclaimed, and if we couldn't
find the node for the rvalue, we just give up. This patch changes that so
that we look for the node for either the rvalue or the lvalue -- preferring
the former, since it lets us fall back to value-only tracking in cases
where we can't get a region, but allowing the latter as well.
<rdar://problem/13342842>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176737 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, ReturnVisitor waited to suppress a null return path until it
had found the inlined "return" statement. Now, it checks up front whether
the return value was NULL, and suppresses the warning right away if so.
We still have to wait until generating the path notes to invalidate the bug
report, or counter-suppression will never be triggered. (Counter-suppression
happens while generating path notes, but the generation won't happen for
reports already marked invalid.)
This isn't actually an issue today because we never reclaim nodes for
top-level statements (like return statements), but it could be an issue
some day in the future. (But, no expected behavioral change and no new
test case.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176736 91177308-0d34-0410-b5e6-96231b3b80d8
This was causing correctness issues for ARC and the static analyzer when a
function template has "consumed" Objective-C object parameters (i.e.
parameters that will be released by the function before returning).
The fix is threefold:
(1) Actually copy over the attributes from old ParmVarDecls to new ones.
(2) Have Sema::BuildFunctionType only work for building FunctionProtoTypes,
which it was doing anyway. This allows us to pass an ExtProtoInfo
instead of a plain ExtInfo and several flags.
(3) Drop param attributes as part of StripImplicitInstantiation, which is
used when an implicit instantiation is followed by an explicit one.
<rdar://problem/12685622>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176728 91177308-0d34-0410-b5e6-96231b3b80d8
We were transforming the scope type of a pseudo-destructor expression
(e.g., the first T in x->T::~T()) as a freestanding type, which meant
that dependent template specialization types here would stay dependent
even when no template parameters were named. This would eventually
mean that a dependent expression would end up in what should be
fully-instantiated ASTs, causing IRgen to assert.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176723 91177308-0d34-0410-b5e6-96231b3b80d8
1. We now ignore all non-default string literals, including raw
literals.
2. We do not break inside escape sequences any more.
FIXME: We still break in trigraphs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176710 91177308-0d34-0410-b5e6-96231b3b80d8
It passes to the visitor, that the caller provides, CXCursor_InclusionDirective cursors for
all the include directives in a particular file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176682 91177308-0d34-0410-b5e6-96231b3b80d8
commands; top level tags such as @interface and
their 2nd level tags such as @coclass, etc.
// rdar://12379114
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176667 91177308-0d34-0410-b5e6-96231b3b80d8
MaxAtomicPromoteWidth. Fix a ton of terrible bugs with
_Atomic types and (non-intrinsic-mediated) loads and stores
thereto.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176658 91177308-0d34-0410-b5e6-96231b3b80d8
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176656 91177308-0d34-0410-b5e6-96231b3b80d8
With the cursor located at "I", clang-format would not do anything to:
int a;
I
int b;
With this patch, it reduces the number of empty lines as necessary, and
removes unnecessary whitespace. It does not change/reformat "int a;" or
"int b;".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176650 91177308-0d34-0410-b5e6-96231b3b80d8
There is now a single function to get the list of phases for a given
output Type.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176628 91177308-0d34-0410-b5e6-96231b3b80d8
string to be emitted, and two properties about the files themselves.
Use $PWD to absolut-ify the path to the coverage file. Yes, this is what GCC
does. Reverts my own r175706.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176617 91177308-0d34-0410-b5e6-96231b3b80d8
Warn about null pointer dereference earlier when a reference to a null pointer is
passed in a call. The idea is that even though the standard might allow this, reporting
the issue earlier is better for diagnostics (the error is reported closer to the place where
the pointer was set to NULL). This also simplifies analyzer’s diagnostic logic, which has
to track “where the null came from”. As a consequence, some of our null pointer
warning suppression mechanisms started triggering more often.
TODO: Change the name of the file and class to reflect the new check.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176612 91177308-0d34-0410-b5e6-96231b3b80d8
It is possible that some of the current uses of
"getStorageClassAsWritten() == SC_Extern" should use this but I don't know
enough about SC_PrivateExtern to change and test them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176606 91177308-0d34-0410-b5e6-96231b3b80d8
Officially in the C++ standard, a null reference cannot exist. However,
it's still very easy to create one:
int &getNullRef() {
int *p = 0;
return *p;
}
We already check that binds to reference regions don't create null references.
This patch checks that we don't create null references by returning, either.
<rdar://problem/13364378>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176601 91177308-0d34-0410-b5e6-96231b3b80d8
that adds ivars to an interface.
Fixes rdar://13175234
This is an update to r176116 that performs a smart caching of interfaces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176584 91177308-0d34-0410-b5e6-96231b3b80d8
The second modification does not lead to any visible result, but, theoretically, is what we should
have been looking at to begin with since we are checking if the node was assumed to be null in
an inlined function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176576 91177308-0d34-0410-b5e6-96231b3b80d8
Stat'ing all the headers from the PCH to make sure they are up-to-date takes significant time.
In a particular source file (whose PCH file included Cocoa.h) from total -fsyntax-only time
12% was just stat calls. Change pre-validation to only check non-system headers.
There are some notable disadvantages:
-If a system header, that is not include-guarded, changes after the PCH was created, we will not
find it in the header info table and we will #import it, effectively #importing it twice, thus
we will emit some error due to a multiple definition and after that the "header was modified" error will likely
be emitted, for example something like:
NSDictionary.h:12:1: error: duplicate interface definition for class 'NSDictionary'
@interface NSDictionary : NSObject <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration>
^
NSDictionary.h:12:12: note: previous definition is here
@interface NSDictionary : NSObject <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration>
^
fatal error: file 'NSDictionary.h' has been modified since the precompiled header was built
Though we get the "header was modified" error, this is a bit confusing.
-Theoretically it is possible that such a system header will cause no errors but it will just cause an
unfortunate semantic change, though I find this rather unlikely.
The advantages:
-Reduces compilation time when using a huge PCH like the Cocoa ones
-System headers change very infrequent and when they do, users/build systems should be able to know that
re-building from scratch is needed.
Addresses rdar://13056262
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176567 91177308-0d34-0410-b5e6-96231b3b80d8
Previously the hash would be the filename portion of the path, which could be
different for a filename with different case or a symbolic link with a different
name completely.
This did not actually create any issue so far because by validating all headers
in the PCH we created uniqued FileEntries based on inodes, so an #include of
a symbolic link (refering to a file from the PCH) would end up with a FileEntry
with filename same as the one recorded in the PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176566 91177308-0d34-0410-b5e6-96231b3b80d8
can't have default arguments even though it's a parameter-declaration-clause in
a function declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176542 91177308-0d34-0410-b5e6-96231b3b80d8
continue parsing the directive rather than silently discarding it.
Allowing undef or redef of __TIME__ and __DATE__ is important to folks
who want stable, reproducible builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176540 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is designed for minimal intrusion into normal preprocessing
and compilation; under -E -traditional-cpp, the lexer will still
generate tok::comment nodes since it is preserving all whitespace, but
the output printer will then throw it away.
<rdar://problem/13338680>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176534 91177308-0d34-0410-b5e6-96231b3b80d8
It's beneficial when compiling to treat // as the start of a line
comment even in -std=c89 mode, since it's not valid C code (with a few
rare exceptions) and is usually intended as such. We emit a pedantic
warning and then continue on as if line comments were enabled.
This has been our behavior for quite some time.
However, people use the preprocessor for things besides C source files.
In today's prompting example, the input contains (unquoted) URLs, which
contain // but should still be preserved.
This change instructs the lexer to treat // as a plain token if Clang is
in C90 mode and generating preprocessed output rather than actually compiling.
<rdar://problem/13338743>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176526 91177308-0d34-0410-b5e6-96231b3b80d8
field to be memcpy'd, rather instead of ASTContext::getTypeAlign(<Field Type>).
For packed structs the alignment of a field may be less than the alignment of
the field's type.
<rdar://problem/13338585>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176512 91177308-0d34-0410-b5e6-96231b3b80d8
'R' An address that can be sued in a non-macro load or store.
Including missing positive test case and fixed typo for r176453.
Thanks to Richard Smith for catching this!
Jack
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176506 91177308-0d34-0410-b5e6-96231b3b80d8
[[noreturn]] function are not required to also be [[noreturn]]. We still emit
calls to virtual __attribute__((noreturn)) functions as noreturn; unlike GCC,
we do require overriders to also be noreturn for that attribute.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176476 91177308-0d34-0410-b5e6-96231b3b80d8
We weren't treating a cf_audited_transfer CFRetain as returning +1 because
its name doesn't contain "Create" or "Copy". Oops! Fortunately, the
standard definitions of these functions are not marked audited.
<rdar://problem/13339601>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176463 91177308-0d34-0410-b5e6-96231b3b80d8
* Use the term 'command marker', because the semantics of 'backslash' and 'at'
commands are the same. (Talking about 'at commands' makes them look like a
special entity.)
* Sink the flag down into bitfields, reducing the size of AST nodes.
* Change the flag into an enum for clarity. Boolean function parameters are
not very clear.
* Add unittests for new tok::at_command tokens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176461 91177308-0d34-0410-b5e6-96231b3b80d8
svn 170909 added support for cortex-r5 but in this case it was done
incorrectly. The last argument to StringSwitch.Cases() is the replacement
value, so by adding "cortex-r5" it changed the default cpu for armv7r to
cortex-r5 instead of cortex-r4.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176456 91177308-0d34-0410-b5e6-96231b3b80d8
'R' An address that can be sued in a non-macro load or store.
This patch includes a positive test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176453 91177308-0d34-0410-b5e6-96231b3b80d8
llvm::sys::fs::equivalent() does 2 stat calls every time it's called. Use FileManager::getFile() to take advantage
of the stat caching that FileManager is providing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176450 91177308-0d34-0410-b5e6-96231b3b80d8
With [] marking the selected range, clang-format invoked on
[ ] int a;
Would so far not reformat anything. With this patch, it formats a
line if its leading whitespace is touched.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176435 91177308-0d34-0410-b5e6-96231b3b80d8
with both -static-libgcc and -static on the commandline.
Fix a warning in the latter case due to a backwards short circuiting ||
operator in the driver. No real functionality changed here, just allows
the driver to properly consume -static-libgcc when -static is also
specified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176429 91177308-0d34-0410-b5e6-96231b3b80d8
- Generate atomicrmw operations in most of the cases when it's sensible to do
so.
- Don't crash in several common cases (and hopefully don't crash in more of
them).
- Add some better tests.
We now generate significantly better code for things like:
_Atomic(int) x;
...
x++;
On MIPS, this now generates a 4-instruction ll/sc loop, where previously it
generated about 30 instructions in two nested loops. On x86-64, we generate a
single lock incl, instead of a lock cmpxchgl loop (one instruction instead of
ten).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176420 91177308-0d34-0410-b5e6-96231b3b80d8
Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.
This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is
suppressed.
There are several areas for follow up work, for example:
- How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?
Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176402 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were assuming that we'd never ask for the sub-region bindings
of a bitfield, since a bitfield cannot have subregions. However,
unification of code paths has made that assumption invalid. While we could
take advantage of this by just checking for the single possible binding,
it's probably better to do the right thing, so that if/when we someday
support unions we'll do the right thing there, too.
This fixes a handful of false positives in analyzing LLVM.
<rdar://problem/13325522>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176388 91177308-0d34-0410-b5e6-96231b3b80d8
in AST for source fidelity and use it in diagnostics
to refer to the original format. // rdar://13066276
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176387 91177308-0d34-0410-b5e6-96231b3b80d8
Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot so that you can
assign into it. However, if the value type is a pointer, it will be
initialized to null. This is usually no problem.
However, if the user /knows/ the map contains a value for a particular key,
they may just use it immediately:
// From ClangSACheckersEmitter.cpp
recordGroupMap[group]->Checkers
In this case the analyzer reports a null dereference on the path where the
key is not in the map, even though the user knows that path is impossible
here. They could silence the warning by adding an assertion, but that means
splitting up the expression and introducing a local variable. (Note that
the analyzer has no way of knowing that recordGroupMap[group] will return
the same reference if called twice in a row!)
We already have logic that says a null dereference has a high chance of
being a false positive if the null came from an inlined function. This
patch simply extends that to references whose rvalues are null as well,
silencing several false positives in LLVM.
<rdar://problem/13239854>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176371 91177308-0d34-0410-b5e6-96231b3b80d8
In builder type call, we indent to the laster function calls.
However, for the last element of such a call, we don't need to do
so, as that normally just wastes space and does not increase
readability.
Before:
aaaaaa->aaaaaa->aaaaaa( // break
aaaaaa);
aaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaa
->aaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaa->aaaaaa->aaaaaa( // break
aaaaaa);
aaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176352 91177308-0d34-0410-b5e6-96231b3b80d8
We now break at a slash if we do not find a space to break on.
Also fixes a bug where we would go over the limit when breaking the
second line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176350 91177308-0d34-0410-b5e6-96231b3b80d8
If we don't find a natural split point (currently space) in a string
literal protruding over the line, we just split at the last possible
point.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176349 91177308-0d34-0410-b5e6-96231b3b80d8
whether we already have a method. Fixes a bug where we were
failing to properly contextually convert a message receiver
during template instantiation.
As a side-effect, we now actually perform correct method lookup
after adjusting a message-send to integral or non-ObjC pointer
types (legal outside of ARC).
rdar://13305374
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176339 91177308-0d34-0410-b5e6-96231b3b80d8
of block declarators. Document the rule we use.
Also document the rule that Doug implemented a few weeks ago
which drops ownership qualifiers on function result types.
rdar://10127067
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176336 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would return null for an out-of-date file. This inhibited ASTReader::ReadSLocEntry
from creating a FileID to recover gracefully in such a case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176332 91177308-0d34-0410-b5e6-96231b3b80d8
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176286 91177308-0d34-0410-b5e6-96231b3b80d8
have their own code completion comments. Use those in
their properties in this case.
// rdar://12791315
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176271 91177308-0d34-0410-b5e6-96231b3b80d8
This does not yet implement the LimitNode approach discussed.
The impact of this is an O(n) in the number of nodes in the AST
reduction of complexity for certain kinds of matchers (as otherwise the
parent map gets recreated for every new MatchFinder).
See FIXMEs in the comments for the direction of future work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176251 91177308-0d34-0410-b5e6-96231b3b80d8
Two improvements:
1) Always leave at least one space before "\". Otherwise is can look bad
and there is a risk of unwillingly joining to characters to a different
token.
2) Use the full column limit for single-line #defines.
Fixes llvm.org/PR15148
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176245 91177308-0d34-0410-b5e6-96231b3b80d8
By returning the (key, value) binding pairs, we save lookups afterwards.
This also enables further work later on.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176230 91177308-0d34-0410-b5e6-96231b3b80d8
Consider this case:
int *p = 0;
p = getPointerThatMayBeNull();
*p = 1;
If we inline 'getPointerThatMayBeNull', we might know that the value of 'p'
is NULL, and thus emit a null pointer dereference report. However, we
usually want to suppress such warnings as error paths, and we do so by using
FindLastStoreBRVisitor to see where the NULL came from. In this case, though,
because 'p' was NULL both before and after the assignment, the visitor
would decide that the "last store" was the initialization, not the
re-assignment.
This commit changes FindLastStoreBRVisitor to consider all PostStore nodes
that assign to this region. This still won't catches changes made directly
by checkers if they re-assign the same value, but it does handle the common
case in user-written code and will trigger ReturnVisitor's suppression
machinery as expected.
<rdar://problem/13299738>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176201 91177308-0d34-0410-b5e6-96231b3b80d8
This enables constructor inlining for types with non-trivial destructors.
The plan is to enable destructor inlining within the next month, but that
needs further verification.
<rdar://problem/12295329>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176200 91177308-0d34-0410-b5e6-96231b3b80d8
single translation unit should prevent later phases from executing. Otherwise,
this generates lots of noise in build systems. This a fallout from r173825.
Patch by Matthew Curtis <mcurtis@codeaurora.org>.
rdar://13298009
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176198 91177308-0d34-0410-b5e6-96231b3b80d8
After some discussions, it seems that this is the better path in
the long run. Does not change Chromium style, as there, bin packing
is forbidden by the style guide.
Also fix two minor bugs wrt. formatting:
1. If a call parameter is a function call itself and is split before
the "." or "->", split before the next parameter.
2. If a call parameter is string literal that has to be split onto
two lines, split before the next parameter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176177 91177308-0d34-0410-b5e6-96231b3b80d8
Since r175326 an implicitly hidden template argument can cause a template
installation to become hidden, even if the template itself has an explicit
default visibility. This requires that we keep track of "late" additions
of the visibility attribute.
This is hopefully the last followup change. It just removes the caching of
visibilities from types so that we can see new attributes even after a type has
been used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176164 91177308-0d34-0410-b5e6-96231b3b80d8
bitfield. CGBitField::StorageAlignment holds the alignment in chars, but
emitMemcpy had been treating it as if it were held in bits, leading to
underaligned memcpys.
Related to PR15348.
Thanks very much to Chandler for the diagnosis.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176163 91177308-0d34-0410-b5e6-96231b3b80d8
Everything that cares about visibility also cares about linkage, so I just
moved it to Visibility.h instead of creating a new .h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176155 91177308-0d34-0410-b5e6-96231b3b80d8
This potentially reduces a performance optimization of throwing away
PreStmtPurgeDeadSymbols nodes. I'll investigate the performance impact
soon and see if we need something better.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176149 91177308-0d34-0410-b5e6-96231b3b80d8
think of them as having return values that may be computed. Don't
warn when using @return in their comment. // rdar://13189938
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176147 91177308-0d34-0410-b5e6-96231b3b80d8
This is essentially the same problem as r174031: a lazy binding for the first
field of a struct may stomp on an existing default binding for the
entire struct. Because of the way RegionStore is set up, we can't help
but lose the top-level binding, but then we need to make sure that accessing
one of the other fields doesn't come back as Undefined.
In this case, RegionStore is now correctly detecting that the lazy binding
we have isn't the right type, but then failing to follow through on the
implications of that: we don't know anything about the other fields in the
aggregate. This fix adds a test when searching for other kinds of default
values to see if there's a lazy binding we rejected, and if so returns
a symbolic value instead of Undefined.
The long-term fix for this is probably a new Store model; see
<rdar://problem/12701038>.
Fixes <rdar://problem/13292559>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176144 91177308-0d34-0410-b5e6-96231b3b80d8
isBeforeInTranslationUnit() uses a cache to reduce the expensive work
to compute a common ancestor for two FileIDs. This work is very
expensive, so even caching the latest used FileIDs was a big win.
A closer analysis of the cache before, however, shows that the cache
access pattern would oscillate between a working set of FileIDs, and
thus caching more pairs would be profitable.
This patch adds a side table for extending caching. This side table
is bounded in size (experimentally determined in this case from
a simple Objective-C project), and when the table gets too large
we fall back to the single entry caching before as before.
On Sketch (a small example Objective-C project), this optimization
reduces -fsyntax-only time on SKTGraphicView.m by 5%. This is
for a project that is already using PCH.
Fixes <rdar://problem/13299847>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176142 91177308-0d34-0410-b5e6-96231b3b80d8
This is causing some problems with some of the builders. It's non-trivial to
reset the target's features.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176133 91177308-0d34-0410-b5e6-96231b3b80d8
This would error in C++ mode unless the variable also had a cv
qualifier.
e.g.
__attribute__((address_space(2))) float foo = 1.0f; would error but
__attribute__((address_space(2))) const float foo = 1.0f; would not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176121 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes PR15358 and <rdar://problem/13295437>.
Along the way, shorten path diagnostics that say "Variable 'x'" to just
be "'x'". By the context, it is obvious that we have a variable,
and so this just consumes text space.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176115 91177308-0d34-0410-b5e6-96231b3b80d8
Now that implicitly hidden template arguments can make an instantiation hidden,
it is important to look at more than just the canonical decl of the argument
in order to see if an attribute is available in a more recent decl.
This has the disadvantage of exposing when getExplicitVisibility is called,
but lets us handle cases like
template <typename T>
struct __attribute__((visibility("default"))) barT {
static void zed() {}
};
class foo;
class __attribute__((visibility("default"))) foo;
template struct barT<foo>;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176112 91177308-0d34-0410-b5e6-96231b3b80d8
GCC applies a pragma weak to a decl if it matches the mangled name. We used
to apply if it matched the plain name.
This patch is a compromise: we apply the pragma only if it matches the name
and the decl has C language linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176110 91177308-0d34-0410-b5e6-96231b3b80d8
Empty lines followed by line comments are often used to highlight the
comment. Empty lines somewhere else are usually left over from manual or
automatic formatting and should probably be removed.
Before (clang-format would keep):
S s = {
a,
b
};
After:
S s = { a, b };
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176086 91177308-0d34-0410-b5e6-96231b3b80d8
We might want to move towards doing this if the formatting can be
significantly improved, but we need to carefully evaluate the different
situations first.
Before (the string literal was split by clang-format here):
aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaa, aaaaaa("aaa aaaaa aaa aaa aaaaa aaa "
"aaaaa aaa aaa aaaaaa"));
After:
aaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaa,
aaaaaa("aaa aaaaa aaa aaa aaaaa aaa aaaaa aaa aaa aaaaaa"));
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176084 91177308-0d34-0410-b5e6-96231b3b80d8
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176076 91177308-0d34-0410-b5e6-96231b3b80d8
Normally, we need to look through derived-to-base casts when creating
temporary object regions (added in r175854). However, if the temporary
is a pointer (rather than a struct/class instance), we need to /preserve/
the base casts that have been applied.
This also ensures that we really do create a new temporary region when
we need to: MaterializeTemporaryExpr and lvalue CXXDefaultArgExprs.
Fixes PR15342, although the test case doesn't include the crash because
I couldn't isolate it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176069 91177308-0d34-0410-b5e6-96231b3b80d8
With the new support for trivial copy constructors, we are not always
consistent about whether a CXXTempObjectRegion gets reused or created
from scratch, which affects whether qualifiers are preserved. However,
we probably don't care anyway.
This also switches to using the current PrintingPolicy for the type,
which means C++ types don't get a spurious 'struct' prefix anymore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176068 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses a case when we inline a wrong method due to incorrect
dynamic type inference. Specifically, when user code contains a method from init
family, which creates an instance of another class.
Use hasRelatedResultType() to find out if our inference rules should be triggered.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176054 91177308-0d34-0410-b5e6-96231b3b80d8
These nodes are never consulted by any analyzer client code, so they are
used only for machinery for removing dead bindings. Once successor nodes
are generated they can be safely removed.
This greatly reduces the amount of nodes that are generated in some case,
lowering the memory regression when analyzing Sema.cpp introduced by
r176010 from 14% to 2%.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176050 91177308-0d34-0410-b5e6-96231b3b80d8
r175026 added support for default values, but didn't take reference
parameters into account, which expect the default argument to be an
lvalue. Use createTemporaryRegionIfNeeded if we can evaluate the default
expr as an rvalue but the expected result is an lvalue.
Fixes the most recent report of PR12915. The original report predates
default argument support, so that can't be it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176042 91177308-0d34-0410-b5e6-96231b3b80d8
Don't print the semicolon when visiting an empty declaration because the semicolon
will be printed as a terminator later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176035 91177308-0d34-0410-b5e6-96231b3b80d8
While RegionStore checks to make sure casts on TypedValueRegions are valid,
it does not do the same for SymbolicRegions, which do not have perfect type
info anyway. Additionally, MemRegion::getAsOffset does not take a
ProgramState, so it can't use dynamic type info to determine a better type
for the regions. (This could also be dangerous if the type of a super-region
changes!)
Account for this by checking that a base object region is valid on top of a
symbolic region, and falling back to "symbolic offset" mode if not.
Fixes PR15345.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176034 91177308-0d34-0410-b5e6-96231b3b80d8
David Blaikie
Fariborz Jahanian
Benjamin Kramer
Jordan Rose
Alexander Kornienko
Alexander Potapenko
Douglas Gregor
John McCall
Richard Smith
Reid Kleckner
James Dennett
Manman Ren
Daniel Jasper
Hans Wennborg
Rafael Espindola
Nick Lewycky
Anna Zaks
Alexey Samsonov
Argyrios Kyrtzidis
Reed Kotler
Anton Korobeynikov
Richard Trieu
Ted Kremenek
Daniel Dunbar
Edwin Vane
Bob Wilson
Adrian Prantl
Sylvestre Ledru
Nico Weber
Manuel Klimek
Joey Gouly
Bill Wendling
Anton Yartsev
Jim Grosbach
Matthew Curtis
Guy Benyei
Dmitri Gribenko
Weiming Zhao
Lang Hames
Jack Carter
Tom Stellard
Chandler Carruth
David Chisnall
Peter Collingbourne
Stefanus Du Toit
Evgeniy Stepanov
Chad Rosier
Simon Atanasyan
Timur Iskhodzhanov
Matt Arsenault
Matt Beaumont-Gay
Kostya Serebryany
Will Dietz
Michael Han