| Age | Commit message (Collapse) | Author |
|---|
|
to prevent an edge being optimized away.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181088 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
same statement parents.
This change required some minor changes to LocationContextMap to have it map
from PathPieces to LocationContexts instead of PathDiagnosticCallPieces to
LocationContexts. These changes are in the other diagnostic
generation logic as well, but are functionally equivalent.
Interestingly, this optimize requires delaying "cleanUpLocation()" until
later; possibly after all edges have been optimized. This is because
we need PathDiagnosticLocations to refer to the semantic entity (e.g. a statement)
as long as possible. Raw source locations tell us nothing about
the semantic relationship between two locations in a path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181084 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Not guaranteed to do anything useful yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180747 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(through indirection) PathDiagnosticPieces."
Jordan rightly pointed out that we can do the same with std::list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
indirection) PathDiagnosticPieces.
Much of this patch outside of PathDiagnostics.h are just minor
syntactic changes due to the return type for operator* and the like
changing for the iterator, so the real focus should be on
PathPieces itself.
This change is motivated so that we can do efficient insertion
and removal of individual pieces from within a PathPiece, just like
this was a kind of "IR" for static analyzer diagnostics. We
currently implement path transformations by iterating over an
entire PathPiece and making a copy. This isn't very natural for
some algorithms.
We use an ilist here instead of std::list because we want operations
to rip out/insert nodes in place, just like IR manipulation. This
isn't being used yet, but opens the door for more powerful
transformation algorithms on diagnostic paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180741 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PathDiagnosticLocation::createEndOfPath for greater code reuse
The 2 functions were computing the same location using different logic (each one had edge case bugs that the other
one did not). Refactor them to rely on the same logic.
The location of the warning reported in text/command line output format will now match that of the plist file.
There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the
operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and
looks better in most cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180165 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also removes some redundant DNI comments on function declarations already
using the macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
brought into 'clang' namespace by clang/Basic/LLVM.h
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The issue here is that if we have 2 leaks reported at the same line for
which we cannot print the corresponding region info, they will get
treated as the same by issue_hash+description. We need to AUGMENT the
issue_hash with the allocation info to differentiate the two issues.
Add the "hash" (offset from the beginning of a function) representing
allocation site to solve the issue.
We might want to generalize solution in the future when we decide to
track more than just the 2 locations from the diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171825 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a simpler sort, entirely automatic with the help of
llvm/utils/sort_includes.py -- no manual edits here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
path notes for cases where a value may be assumed to be null, etc.
Instead of having redundant diagnostics, do a pass over the generated
PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor
that are already covered by ConditionBRVisitor, whose notes tend
to be better.
Fixes <rdar://problem/12252783>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166728 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Updates to llvm/Support/Casting.h have rendered these classof()'s
irrelevant.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165770 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Somewhat troublingly, without this implemented, the check inside
isa_impl<> would silently use the parent's `classof()` when determining
whether it was okay to downcast from the parent to the child!
Bug analysis:
A build failure after removing the parent's `classof()` initially
alerted me to the bug, after which a little bit of thinking and reading
of the code identified the root cause.
The compiler could be made to prevent this bug from happening if there
were a way to ensure that in the code
template <typename To, typename From, typename Enabler = void>
struct isa_impl {
static inline bool doit(const From &Val) {
return To::classof(&Val);
}
};
that `To::classof` is actually inside the class `To`, and not in a base
class. I am not aware of a way to check this in C++. If there is a means
to perform that check, please bring it up on the list and this will be
fixed.
There is a high likelihood that there are other instances of this same
bug in the codebase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165769 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Just a refactoring of common infrastructure. No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM_DELETED_FUNCTION.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164102 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of a std::string.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163488 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PathDiagnostics are actually profiled and uniqued independently of the
path on which the bug occurred. This is used to merge diagnostics that
refer to the same issue along different paths, as well as by the plist
diagnostics to reference files created by the HTML diagnostics.
However, there are two problems with the current implementation:
1) The bug description is included in the profile, but some
PathDiagnosticConsumers prefer abbreviated descriptions and some
prefer verbose descriptions. Fixed by including both descriptions in
the PathDiagnostic objects and always using the verbose one in the profile.
2) The "minimal" path generation scheme provides extra information about
which events came from macros that the "extensive" scheme does not.
This resulted not only in different locations for the plist and HTML
diagnostics, but also in diagnostics being uniqued in the plist output
but not in the HTML output. Fixed by storing the "end path" location
explicitly in the PathDiagnostic object, rather than trying to find the
last piece of the path when the diagnostic is requested.
This should hopefully finish unsticking our internal buildbot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
generated for a given diagnostic to another. Because PathDiagnostics
are specific to a give PathDiagnosticConsumer, store in
a FoldingSet a unique hash for a PathDiagnostic (that will be the same
for the same bug for different PathDiagnosticConsumers) that
stores a list of files generated. This can then be read by the
other PathDiagnosticConsumers.
This fixes breakage in the PLIST-HTML output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162580 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ArrayRef<SourceRange> for ranges. This
removes conceptual clutter, and can allow us to easy migrate to C++11 style for-range loops if we
ever move to using C++11 in Clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162029 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162028 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).
This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:
testMultipleInheritance3
~MultipleInheritance
~SmartPointer
~Subclass
~SmartPointer
***bug here***
In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.
Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.
(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160804 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is needed to ensure that we always report issues in the correct
function. For example, leaks are identified when we call remove dead
bindings. In order to make sure we report a callee's leak in the callee,
we have to run the operation in the callee's context.
This change required quite a bit of infrastructure work since:
- We used to only run remove dead bindings before a given statement;
here we need to run it after the last statement in the function. For
this, we added additional Program Point and special mode in the
SymbolReaper to remove all symbols in context lower than the current
one.
- The call exit operation turned into a sequence of nodes, which are
now guarded by CallExitBegin and CallExitEnd nodes for clarity and
convenience.
(Sorry for the long diff.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155244 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
analyzer issue occurred in the plist output.
Fixes <rdar://problem/11004527>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154030 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152982 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Do not display the standard "Returning from 'foo'", when a stack hint is
available.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The symbol-aware stack hint combines the checker-provided message
with the information about how the symbol was passed to the callee: as
a parameter or a return value.
For malloc, the generated messages look like this :
"Returning from 'foo'; released memory via 1st parameter"
"Returning from 'foo'; allocated memory via 1st parameter"
"Returning from 'foo'; allocated memory returned"
"Returning from 'foo'; reallocation of 1st parameter failed"
(We are yet to handle cases when the symbol is a field in a struct or
an array element.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152962 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
BugVisitor DiagnosticPieces.
When checkers create a DiagnosticPieceEvent, they can supply an extra
string, which will be concatenated with the call exit message for every
call on the stack between the diagnostic event and the final bug report.
(This is a simple version, which could be/will be further enhanced.)
For example, this is used in Malloc checker to produce the ",
which allocated memory" in the following example:
static char *malloc_wrapper() { // 2. Entered call from 'use'
return malloc(12); // 3. Memory is allocated
}
void use() {
char *v;
v = malloc_wrapper(); // 1. Calling 'malloc_wrappers'
// 4. Returning from 'malloc_wrapper', which allocated memory
} // 5. Memory is never released; potential
memory leak
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152837 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152742 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the callee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152734 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
symbols and regions.
Essentially, a bug centers around a story for various symbols and regions. We should only include
the path diagnostic events that relate to those symbols and regions.
The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
can be modified at BugReport creation or by BugReporterVisitors.
This patch reduces the diagnostics emitted in several of our test cases. I've vetted these as
having desired behavior. The only regression is a missing null check diagnostic for the return
value of realloc() in test/Analysis/malloc-plist.c. This will require some investigation to fix,
and I have added a FIXME to the test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the callee, and add an edge.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152086 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
don't support cross-file diagnostics
into a common place. Currently enable this filtration for Plist diagnostics as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151664 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
unnecessary cruft caused by path inlining.
This introduces a concept of a "prunable" PathDiagnosticEvent. Currently this is a flag, but
we may evolve the concept to make this more dynamically inferred.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151663 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
into account the nested structure. Also fix a problem with how
inlining impacted Plist diagnostics, and adjust some ranges in the Plist output due to richer information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PathDiagnosticCallPiece.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151317 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The class name is long enough without the llvm:: added.
Also bring in RefCountedBase and RefCountedBaseVPTR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
management), and introduce 'PathPieces' as a common container for PathDiagnosticPieces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150054 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in PathDiagnostics from other events. This will
have potential uses later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149960 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
They were unused and pulled in Diagnostic.h for no reason.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reports are batched up before being flushed
to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which
shows up with inlining).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148997 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
accurate, but it frees up the name AnalysisContext for other uses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140492 91177308-0d34-0410-b5e6-96231b3b80d8
|
