We don't need a new ExpectedOutputs/ convention. Expected outputs are
just another form of test input.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@339634 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@339475 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334524 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251011 91177308-0d34-0410-b5e6-96231b3b80d8
...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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183165 91177308-0d34-0410-b5e6-96231b3b80d8
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
The actual change here is a little more complicated than the summary above.
What we want to do is have our generic inlining tests run under whatever
mode is the default. However, there are some tests that depend on the
presence of C++ inlining, which still has some rough edges. These tests have
been explicitly marked as -analyzer-ipa=inlining in preparation for a new
mode that limits inlining to C functions and blocks. This will be the
default until the false positives for C++ have been brought down to
manageable levels.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162317 91177308-0d34-0410-b5e6-96231b3b80d8
engine.
The code that was supposed to split the tie in a deterministic way is
not deterministic. Most likely one of the profile methods uses a
pointer. After this change we do finally get the consistent diagnostic
output. Testing this requires running the analyzer on large code bases
and diffing the results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161224 91177308-0d34-0410-b5e6-96231b3b80d8
we use the same Expr* as the one being currently visited. This is preparation for transitioning to having
ProgramPoints refer to CFGStmts.
This required a bit of trickery. We wish to keep the old Expr* bindings in the Environment intact,
as plenty of logic relies on it and there is no reason to change it, but we sometimes want the Stmt* for
the ProgramPoint to be different than the Expr* being used for bindings. This requires adding an extra
argument for some functions (e.g., evalLocation). This looks a bit strange for some clients, but
it will look a lot cleaner when were start using CFGStmt* in the appropriate places.
As some fallout, the diagnostics arrows are a bit difference, since some of the node locations have changed.
I have audited these, and they look reasonable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154214 91177308-0d34-0410-b5e6-96231b3b80d8
inlining to be the reverse of their declaration.
This optimizes running time under inlining up to 20% since we do not
re-analyze the utility functions which are usually defined first in the
translation unit if they have already been analyzed while inlined into
the root functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152653 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
Mikhail Maltsev