| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
point to the
FunctionDecl that we are importing the FunctionProtoType for, in which case we'll have
infinite recursion when importing.
Initially create a FunctionProtoType with null ExceptionSpecDecl/ExceptionSpecTemplate and
update the type in ASTNodeImporter::VisitFunctionDecl after the FunctionDecl has been created.
llvm-svn: 164450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a heuristic intended to greatly reduce the number of false
positives resulting from inlining, particularly inlining of generic,
defensive C++ methods that live in header files. The suppression is
triggered in the cases where we ask to track where a null pointer came
from, and it turns out that the source of the null pointer was an inlined
function call.
This change brings the number of bug reports in LLVM from ~1500 down to
around ~300, a much more manageable number. Yes, some true positives may
be hidden as well, but from what I looked at the vast majority of silenced
reports are false positives, and many of the true issues found by the
analyzer are still reported.
I'm hoping to improve this heuristic further by adding some exceptions
next week (cases in which a bug should still be reported).
llvm-svn: 164449
|
| |
|
|
|
|
|
| |
Also, tidy up the other tracking visitors so that they mark the right
things as interesting and don't do extra work.
llvm-svn: 164448
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, PathDiagnosticConsumers that did not support actual path output
would (sensibly) cause the generation of the full path to be skipped.
However, BugReporterVisitors may want to see the path in order to mark a
BugReport as invalid.
Now, even for a path generation scheme of 'None' we will still create a
trimmed graph and walk backwards through the bug path, doing no work other
than passing the nodes to the BugReporterVisitors. This isn't cheap, but
it's necessary to properly do suppression when the first path consumer does
not support path notes.
In the future, we should try only generating the path and visitor-provided
path notes once, or at least only creating the trimmed graph once.
llvm-svn: 164447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to allow visitors to make decisions about whether a
BugReport is likely a false positive. Currently there are no visitors
making use of this feature, so there are no tests.
When a BugReport is marked invalid, the invalidator must provide a key
that identifies the invaliation (intended to be the visitor type and a
context pointer of some kind). This allows us to reverse the decision
later on. Being able to reverse a decision about invalidation gives us more
flexibility, and allows us to formulate conditions like "this report is
invalid UNLESS the original argument is 'foo'". We can use this to
fine-tune our false-positive suppression (coming soon).
llvm-svn: 164446
|
| |
|
|
|
|
|
| |
This allows us to show /why/ a particular object is nil, even when it is
wrapped in an OpaqueValueExpr.
llvm-svn: 164445
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than saying "Null pointer value stored to 'foo'", we now say
"Passing null pointer value via Nth parameter 'foo'", which is much better.
The note is also now on the argument expression as well, rather than the
entire call.
This paves the way for continuing to track arguments back to their sources.
<rdar://problem/12211490>
llvm-svn: 164444
|
| |
|
|
|
|
| |
Just a refactoring of common infrastructure. No intended functionality change.
llvm-svn: 164443
|
| |
|
|
|
|
|
|
|
|
|
| |
Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path notes:
PointObj *p = nil;
int *px = &p->_x; // should warn here
*px = 1;
llvm-svn: 164442
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to catch cases like this early, so that we can produce better
diagnostics and path notes:
Point *p = 0;
int *px = &p->x; // should warn here
*px = 1;
llvm-svn: 164441
|
| |
|
|
|
|
|
| |
fatal error. Previously, if a fatal error was followed by a diagnostic which
was suppressed due to a SFINAETrap, we'd forget that we'd seen a fatal error.
llvm-svn: 164437
|
| |
|
|
| |
llvm-svn: 164421
|
| |
|
|
|
|
|
|
|
| |
that the backend can mark it as the representative pointer for
the block.
rdar://12001329
llvm-svn: 164418
|
| |
|
|
| |
llvm-svn: 164417
|
| |
|
|
|
|
|
|
|
|
| |
don't pass
nodes from the imported ASTContext.
rdar://12348924
llvm-svn: 164416
|
| |
|
|
|
|
|
| |
setter or getter backing a deprecated/unavailable property,
also not location of the property. // rdar://12324295
llvm-svn: 164412
|
| |
|
|
|
|
|
| |
attributes like uwtable. Without uwtable a stack unwinder would be unable
to go past the thunks.
llvm-svn: 164411
|
| |
|
|
|
|
|
|
| |
-mips32, -mips32r2, -mips64, -mips64r2.
The patch reviewed by Eric Christopher.
llvm-svn: 164410
|
| |
|
|
| |
llvm-svn: 164409
|
| |
|
|
|
|
| |
so that they visually look like an AST dump.
llvm-svn: 164401
|
| |
|
|
| |
llvm-svn: 164400
|
| |
|
|
| |
llvm-svn: 164399
|
| |
|
|
| |
llvm-svn: 164397
|
| |
|
|
| |
llvm-svn: 164396
|
| |
|
|
|
|
|
| |
where a call to function marked 'noreturn' is followed by unreachable
implicit destructor calls.
llvm-svn: 164394
|
| |
|
|
|
|
| |
Try this again, now that r164392 is in place.
llvm-svn: 164393
|
| |
|
|
|
|
| |
them being correctly constructed.
llvm-svn: 164392
|
| |
|
|
| |
llvm-svn: 164391
|
| |
|
|
| |
llvm-svn: 164390
|
| |
|
|
|
|
| |
deterministic. Fixes pr13868.
llvm-svn: 164382
|
| |
|
|
| |
llvm-svn: 164374
|
| |
|
|
|
|
|
|
| |
out bugs."
It crashed test/Analysis/Output/blocks.m on some hosts.
llvm-svn: 164368
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes the wording more informative, and consistent with the other
warnings about uninitialized variables.
Also, me and David who reviewed this couldn't figure out why we would
need to do a lookup to get the name of the variable; so just print the
name directly.
llvm-svn: 164366
|
| |
|
|
| |
llvm-svn: 164364
|
| |
|
|
| |
llvm-svn: 164363
|
| |
|
|
| |
llvm-svn: 164360
|
| |
|
|
| |
llvm-svn: 164359
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
but not
external visible decls, call DeclContext::setMustBuildLookupTable so that the
"lazy decls" bit of the LookupPtr is set.
Previously, in non-C++, if there were no new declarations causing the "lazy decls" bit
to be set, then DeclContext::lookups_begin() would fail to return the decls from the PCH.
Fixes rdar://12316296.
llvm-svn: 164351
|
| |
|
|
| |
llvm-svn: 164348
|
| |
|
|
|
|
|
|
|
|
|
| |
The expression based expansion too often results in IR level optimizations
splitting the intermediate values into separate basic blocks, preventing
the formation of the VBSL instruction as the code author intended. In
particular, LICM would often hoist part of the computation out of a loop.
rdar://11011471
llvm-svn: 164342
|
| |
|
|
| |
llvm-svn: 164341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when
their implementations are unavailable. Start by simulating dispatch_sync().
This change is largely a bunch of plumbing around something very simple. We
use AnalysisDeclContext to conjure up a fake function body (using the
current ASTContext) when one does not exist. This is controlled
under the analyzer-config option "faux-bodies", which is off by default.
The plumbing in this patch is largely to pass the necessary machinery
around. CallEvent needs the AnalysisDeclContextManager to get
the function definition, as one may get conjured up lazily.
BugReporter and PathDiagnosticLocation needed to be relaxed to handle
invalid locations, as the conjured body has no real source locations.
We do some primitive recovery in diagnostic generation to generate
some reasonable locations (for arrows and events), but it can be
improved.
llvm-svn: 164339
|
| |
|
|
| |
llvm-svn: 164338
|
| |
|
|
|
|
| |
construction.
llvm-svn: 164337
|
| |
|
|
| |
llvm-svn: 164336
|
| |
|
|
| |
llvm-svn: 164335
|
| |
|
|
|
|
| |
as exclusive.
llvm-svn: 164332
|
| |
|
|
|
|
| |
lock expressions.
llvm-svn: 164324
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
but can be dereferenced to form an expression which does have viable begin/end
functions, then typo-correct the range, even if something else goes wrong with
the statement (such as inaccessible begin/end or the wrong type of loop
variable).
In order to ensure we recover correctly and produce any followup diagnostics in
this case, redo semantic analysis on the for-range statement outside of the
diagnostic trap, after issuing the typo-correction.
llvm-svn: 164323
|
| |
|
|
|
|
| |
Patch by Sean McBride.
llvm-svn: 164318
|