| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
diff_plist"
Following r363007, which reverted r362998, r362996, and r362994,
reapply with adjustments for the CRLF differences encountered with
Windows. Namely, the `-b` option of `diff` is employed, and the `grep`
patterns have `$` replaced with `[[:space:]]*$`.
llvm-svn: 363069
|
| |
|
|
|
|
|
|
|
|
|
| |
diff_plist"
Reverts r362998, r362996, and r362994 because the tests do not pass on
Windows due to CRLF changes. Adding back `-w` to diff is not enough, the
new grep substitution doesn't work on Windows, and fixing it is
non-trivial.
llvm-svn: 363007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The `%diff_plist` lit substitution invokes `diff` with a non-portable
`-I` option. The intended effect can be achieved by normalizing the
inputs to `diff` beforehand. Such normalization can be done with
`grep -Ev`, which is also used by other tests.
This patch applies the change (adjusted for review comments) described
in http://lists.llvm.org/pipermail/cfe-dev/2019-April/061904.html
mechanically to the cases where the output file is piped to
`%diff_plist` via `cat`.
The changes were applied via a script, except that
`clang/test/Analysis/NewDelete-path-notes.cpp` and
`clang/test/Analysis/plist-macros-with-expansion.cpp` were each adjusted
for the line-continuation on the relevant `RUN` step.
Reviewers: NoQ, sfertile, xingxue, jasonliu, daltenty
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62950
llvm-svn: 362996
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current argument order has "expected" and "actual" the wrong way around,
so that the diff shows the change from expected to actual, not from actual to expected.
Namely, if the expected diagnostics contains the string "foo", but the analyzer emits "bar",
we really want to see:
```
- foo
+ bar
```
not
```
- bar
+ foo
```
since adapting to most changes would require applying that diff to the expected output.
Differential Revision: https://reviews.llvm.org/D56340
llvm-svn: 350866
|
| |
|
|
|
|
|
|
|
| |
This patch defines a new substitution and uses it to reduce
duplication in the Clang Analyzer test cases.
Differential Revision: https://reviews.llvm.org/D52036
llvm-svn: 342365
|
| |
|
|
| |
llvm-svn: 341978
|
| |
|
|
|
|
|
|
|
|
| |
output, update tests""""
This reverts commit 2f5d71d9fa135be86bb299e7d773036e50bf1df6.
Hopefully fixing tests on Windows.
llvm-svn: 341719
|
| |
|
|
|
|
|
|
| |
update tests"""
Reverts analyzer tests from rL341627 again as they still broke windows buildbots
llvm-svn: 341648
|
| |
|
|
|
|
|
|
|
|
| |
tests""
This reverts commit a39bcab414dd7ace7e490363ecdf01ecce7743fc.
Reverting the revert, fixing tests.
llvm-svn: 341627
|
| |
|
|
|
|
|
| |
We don't need a new ExpectedOutputs/ convention. Expected outputs are
just another form of test input.
llvm-svn: 339634
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
files, use diff instead of a FileCheck
Some of the analyzer tests check the exact plist output, in order to
verify that the diagnostics produced is correct.
Current testing setup has many issues:
plist output clobbers tests, making them harder to read
it is impossible to debug test failures given error messages from FileCheck.
The only recourse is manually creating the files and using the diff
again, it is impossible to update the tests given the error message:
the only process is a tedious manual one,
going from a separate plist file to CHECK directives.
This patch offers a much better approach of using "diff" directly in place of FileCheck,
and moving tests to separate files.
Generated using the following script:
```
import os
import glob
import re
import subprocess
diagnostics_key = "// CHECK: <key>diagnostics</key>"
def process_file(f, data):
idx = data.index(diagnostics_key)
plist_out_f = 'ExpectedOutputs/plists/%s.plist' % f
plist_out_folder = os.path.join('ExpectedOutputs/plists/', os.path.dirname(f))
plist_data = data[idx:]
plist_data = plist_data.replace('// CHECK: ', '')
plist_data = plist_data.replace('// CHECK-NEXT: ', '')
plist_data += "</dict>\n</plist>\n"
data = data[:idx]
ptn = re.compile("FileCheck --?input-file(=| )(%t|%t\.plist) %s")
if not ptn.findall(data):
print "none found =/ skipping..."
return
data = ptn.sub(lambda m: "tail -n +11 %s | diff -u -w - %%S/../%s" % (m.group(2), plist_out_f), data)
with open(f, 'w') as out_f:
out_f.write(data)
subprocess.check_call(["mkdir", "-p", plist_out_folder])
with open(plist_out_f, 'w') as out_f:
out_f.write(plist_data)
def main():
files = glob.glob("**/*.*")
for f in files:
with open(f) as f_handler:
data = f_handler.read()
if diagnostics_key in data:
print "Converting %s" %f
process_file(f, data)
if __name__ == "__main__":
main()
```
Differential Revision: https://reviews.llvm.org/D50545
llvm-svn: 339475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename AlternateExtensive to Extensive.
In 2013, five years ago, we have switched to AlternateExtensive
diagnostics by default, and Extensive was available under unused,
undocumented flag.
This change remove the flag, renames the Alternate
diagnostic to Extensive (as it's no longer Alternate), and ports the
test.
Differential Revision: https://reviews.llvm.org/D47670
llvm-svn: 334524
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trying to figure out where a null or undefined value came from,
parentheses and cast expressions are either completely irrelevant, or,
in the case of lvalue-to-rvale cast, straightforwardly lead us in the right
direction when we remove them.
There is a regression that causes a certain diagnostic to appear twice in the
path-notes.cpp test (changed to FIXME). It would be addressed in the next
commit.
Differential revision: https://reviews.llvm.org/D41254
llvm-svn: 321133
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296895
|
| |
|
|
|
|
|
|
| |
multiple constraint managers"
This reverts commit ea36f1406e1f36bf456c3f3929839b024128e468.
llvm-svn: 296841
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296837
|
| |
|
|
|
|
|
|
| |
multiple constraint managers"
This reverts commit f93343c099fff646a2314cc7f4925833708298b1.
llvm-svn: 296836
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296835
|
| |
|
|
|
|
|
|
| |
multiple constraint managers"
This reverts commit 1b28d0b10e1c8feccb971abb6ef7a18bee589830.
llvm-svn: 296422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296414
|
| |
|
|
|
|
|
|
| |
constraint managers"
This reverts commit 8e7780b9e59ddaad1800baf533058d2c064d4787.
llvm-svn: 296317
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296312
|
| |
|
|
|
|
|
|
|
| |
The more detailed diagnostic will make identifying which object the
diagnostics refer to easier.
Differential Revision: https://reviews.llvm.org/D27740
llvm-svn: 289883
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the analyzer's path-sensitive reports, when a report goes through a branch
and the branch condition cannot be decided to be definitely true or false
(based on the previous execution path), an event piece is added that tells the
user that a new assumption is added upon the symbolic value of the branch
condition. For example, "Assuming 'a' is equal to 3".
The text of the assumption is hand-crafted in various manners depending on
the AST expression. If the AST expression is too complex and the text of
the assumption fails to be constructed, the event piece is omitted.
This causes loss of information and misunderstanding of the report.
Do not omit the event piece even if the expression is too complex;
add a piece with a generic text instead.
Differential Revision: https://reviews.llvm.org/D23300
llvm-svn: 283301
|
| |
|
|
| |
llvm-svn: 251014
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds hashes to the plist and html output to be able to identfy bugs
for suppressing false positives or diff results against a baseline. This hash
aims to be resilient for code evolution and is usable to identify bugs in two
different snapshots of the same software. One missing piece however is a
permanent unique identifier of the checker that produces the warning. Once that
issue is resolved, the hashes generated are going to change. Until that point
this feature is marked experimental, but it is suitable for early adoption.
Differential Revision: http://reviews.llvm.org/D10305
Original patch by: Bence Babati!
llvm-svn: 251011
|
| |
|
|
|
|
|
|
|
|
|
| |
to the plist output. This check_name field does not guaranteed to be the
same as the name of the checker in the future.
Reviewer: Anna Zaks
Differential Revision: http://reviews.llvm.org/D6841
llvm-svn: 228624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We process autorelease counts when we exit functions, but if there's an
issue in a synthesized body the report will get dropped. Just skip the
processing for now and let it get handled when the caller gets around to
processing autoreleases.
(This is still suboptimal: objects autoreleased in the caller context
should never be warned about when exiting a callee context, synthesized
or not.)
Second half of <rdar://problem/14611722>
llvm-svn: 187625
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Much of our diagnostic machinery is set up to assume that the report
end path location is valid. Moreover, the user may be quite confused
when something goes wrong in our BodyFarm-synthesized function bodies,
which may be simplified or modified from the real implementations.
Rather than try to make this all work somehow, just drop the report so
that we don't try to go on with an invalid source location.
Note that we still handle reports whose /paths/ go through invalid
locations, just not those that are reported in one.
We do have to be careful not to lose warnings because of this.
The impetus for this change was an autorelease being processed within
the synthesized body, and there may be other possible issues that are
worth reporting in some way. We'll take these as they come, however.
<rdar://problem/14611722>
llvm-svn: 187624
|
| |
|
|
|
|
|
|
|
| |
...but don't yet migrate over the existing plist tests. Some of these
would be trivial to migrate; others could use a bit of inspection first.
In any case, though, the new edge algorithm seems to have proven itself,
and we'd like more coverage (and more usage) of it going forwards.
llvm-svn: 183165
|
| |
|
|
| |
llvm-svn: 182678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.
By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.
<rdar://problem/13978414>
llvm-svn: 182677
|
| |
|
|
|
|
| |
(Modifying the checker to record that the values are no longer nil will be done separately.)
llvm-svn: 181744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were actually two bugs here:
- if we decided to look for an interesting lvalue or call expression, we
wouldn't go find its node if we also knew we were at a (different) call.
- if we looked through one message send with a nil receiver, we thought we
were still looking at an argument to the original call.
Put together, this kept us from being able to track the right values, which
means sub-par diagnostics and worse false-positive suppression.
Noticed by inspection.
llvm-svn: 180996
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 180165
|
| |
|
|
|
|
| |
method not called.
llvm-svn: 179776
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
After:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
The location of the note is already in the caller, not the callee, so this
just brings the "depth" attribute in line with that.
This only affects plist diagnostic consumers (i.e. Xcode). It's necessary
for Xcode to associate the control flow arrows with the right stack frame.
<rdar://problem/13634363>
llvm-svn: 179351
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this code
int getZero() {
return 0;
}
void test() {
int problem = 1 / getZero(); // expected-warning {{Division by zero}}
}
we generate these arrows:
+-----------------+
| v
int problem = 1 / getZero();
^ |
+---+
where the top one represents the control flow up to the first call, and the
bottom one represents the flow to the division.* It turns out, however, that
we were generating the top arrow twice, as if attempting to "set up context"
after we had already returned from the call. This resulted in poor
highlighting in Xcode.
* Arguably the best location for the division is the '/', but that's a
different problem.
<rdar://problem/13326040>
llvm-svn: 179350
|
| |
|
|
|
|
|
|
|
|
|
|
| |
a VarRegion.
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.
llvm-svn: 176115
|
| |
|
|
|
|
| |
This gives more flexibility to what could be stored as issue_hash.
llvm-svn: 171824
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is the case where the analyzer tries to print out source locations
for code within a synthesized function body, which of course does not have
a valid source location. The previous fix attempted to do this during
diagnostic path pruning, but some diagnostics have pruning disabled, and
so any diagnostic with a path that goes through a synthesized body will
either hit an assertion or emit invalid output.
<rdar://problem/12657843> (again)
llvm-svn: 169631
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do this by using the "most recent" good location: if a synthesized
function 'A' calls another function 'B', the path notes for the call to 'B'
will be placed at the same location as the path note for calling 'A'.
Similarly, the call to 'A' will have a note saying "Entered call from...",
and now we just don't emit that (since the user doesn't have a body to look
at anyway).
Previously, we were doing this for the "Calling..." notes, but not for the
"Entered call from..." or "Returning to caller". This caused a crash when
the path entered and then exiting a call within a synthesized body.
<rdar://problem/12657843>
llvm-svn: 168019
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
This allows us to show /why/ a particular object is nil, even when it is
wrapped in an OpaqueValueExpr.
llvm-svn: 164445
|
