Summary:
There's not really a concept of callee here, so s/callee/callsite/, and "to"
suggests we get the callee whereas we update it, so s/to/with/.
Feel free to bikeshed further.
Reviewed By: sblackshear
Differential Revision: D4153426
fbshipit-source-id: 6ea762c
Summary:
It was defined in two places and I'm about to add a third, so let's share
instead.
Reviewed By: sblackshear
Differential Revision: D4153420
fbshipit-source-id: 3d2c519
Summary:
In some error conditions, it could happen that the log file directory
was created early in execution, and then deleted, causing the creation
of log files to then fail.
Reviewed By: sblackshear
Differential Revision: D4157986
fbshipit-source-id: 1548b08
Summary: If a procedure is both a source and a sink for the same value, and it's a sink first, you will get a false positive when applying the summary for the procedure.
Reviewed By: cristianoc
Differential Revision: D4145246
fbshipit-source-id: 97f0022
Summary:
This diff ports checkCopyright to Core, builds it separately from other
executables, and fixes the build command in the linter.
Reviewed By: jvillard
Differential Revision: D4148217
fbshipit-source-id: 8aefc98
Summary: `make test` was always exiting with exit code 0, even in the case of test failures. This is definitely not what we want.
Reviewed By: sblackshear
Differential Revision: D4154912
fbshipit-source-id: 87b4b2b
Summary: Mark native methods as defined so that the analysis generates a summary for those methods. When analyzing Java projects compiled with Buck, the summaries for the dependencies methods of are retrieved from the classpath. In this case, having access to the summary is useful to access the attributes of a callee when the callee is part of a, previously analyzed, Buck target.
Reviewed By: sblackshear
Differential Revision: D4141362
fbshipit-source-id: 75888c8
Summary: This message should be printed in the standard output once all the tests have passed which makes it easier to dinstinguish the cases when some tests fail from the cases where all tests are fine.
Reviewed By: sblackshear
Differential Revision: D4150022
fbshipit-source-id: 6be39c2
Summary:
The syntax highlighting swallows initial '\n' characters in the string, which
caused bugs where infer would report the correct line but not the correct
source excerpt.
Reviewed By: jeremydubreil
Differential Revision: D4153083
fbshipit-source-id: 8b1d211
Summary:
Only the python code passes --models, always does so, and only ever
passes Config.models_jar.
Reviewed By: jeremydubreil
Differential Revision: D4151094
fbshipit-source-id: 8f21c03
Summary:
The way to replace failing tests coming from build_integration_tests.py was not
very discoverable, and now that we have a target for precisely this action we
might as well use it.
The downside is that it's much slower to run `make test-replace` that way but
that's all the more incentive to migrate tests from python to Makefiles. Anyway
most of that time is spend in the buck test, which is going to be migrated
soon.
Reviewed By: jeremydubreil
Differential Revision: D4147121
fbshipit-source-id: 53689e9
Summary:
Move code that initializes the InferAnalyze executable from
InferAnalyze.main to InferAnalyzeExe. This enables InferAnalyze.main to
be called from other executables without conflicts due to
initialization.
Reviewed By: jvillard
Differential Revision: D4137280
fbshipit-source-id: 3dd76db
Summary: Also use the executable as a default name prefix.
Reviewed By: akotulski, jvillard
Differential Revision: D4135539
fbshipit-source-id: 84ba011
Summary:
Analyses should handle methods whose code is unknown and methods whose summary is a no-op differently.
Previously, this was done correctly for some kinds of methods (e.g., native methods, which were recognized as unknown), but not for others (interface and abstract methods).
This diff makes sure we correctly treat all three kinds as unknown.
Reviewed By: jeremydubreil
Differential Revision: D4142697
fbshipit-source-id: c88cff3
Summary:
Location.nLOC was introducing a lot of complexity for little benefit (and edge cases were wrong anyway).
We can restore it in some simplified way if we find that we need it
Reviewed By: jeremydubreil
Differential Revision: D4139868
fbshipit-source-id: 4f8e033
Summary: This fixes the build when `./configure --disable-c-analyzers` is used.
Reviewed By: jberdine
Differential Revision: D4146818
fbshipit-source-id: bec4b48
Summary:
Fix potential performance problems in `CLocation` module
1. Don't call `Unix.stat` to compare files if it's enough to compare paths
2. Use C implementation of `realpath` and call it only when it's really necessary
This diff breaks `Location.nLOC` information for whole clang frontend, but it's going away soon anyway
Reviewed By: jvillard, jberdine
Differential Revision: D4132526
fbshipit-source-id: f01afe8
Summary: Having only place where the code runs the transformation of the Java bytecode into the JBir reporesentation allows to more easily start manipulating the JBir representation and the bytecode together and progressively move the translation based on bytecode instead of JBir.
Reviewed By: sblackshear
Differential Revision: D4137576
fbshipit-source-id: c483528
Summary:
Summaries are modified before saving from disk, for example the attributes of the postcondition can change.
I have observed flaky reports of the internal error NULL_TEST_AFTER_DEREFERENCE. Some attributes (e.g. assigned) are changed before saving, but the spec table in memory is not changed.
So in case:
1) the procedure is analyzed on-demand, then subsequent uses in the same process use the summary in memory with the unchanged attribute, and the issue is not reported.
2) the procedure is already on disk and loaded, then the loaded summary has the changed attributes, and the issue is reported.
Flakiness happens as because of parallelism, whether a procedure is analyzed already or whether it is analyzed on-demand, can change.
The normalization function can change the instrumentation of a symbolic heap because it uses the existing comparison functions, which ignore instrumentations.
So normalization can replace part of a symbolic heap with an identical one but where the instrumentation is different — this is what I have observed.
The diff uses a different comparison function where instrumentations are taken into account.
Reviewed By: jberdine
Differential Revision: D4140031
fbshipit-source-id: f4f119a
Summary:
Instead of the custom filtering done by `InferPrint --issues-tests`, use the
filtering done by `infer` and run without filtering for our e2e tests. We still
test the filtering for our build systems integration tests, and this diff
restores that behaviour for the ant test (hence the bugs removed from
ant/issues.exp).
Also add internal exceptions to most tests to get more signal out of them (eg,
knowing when we add assertion failures and the like).
Retire the old `--issues-tests` to limit the number of ways we do filtering.
Reviewed By: jeremydubreil
Differential Revision: D4131308
fbshipit-source-id: 35805cc
Summary:
curr_file is remnant of the past when we didn't have good location information
coming from Clang_ast_t location. But it was fixed ~1 year ago.
Reviewed By: jvillard
Differential Revision: D4139750
fbshipit-source-id: 4ce7235
Summary:
This will be useful to migrate the existing tests to using report.json to
output the list of bugs found by Infer. This will make the tests reflect what
happens in prod more faithfully: right now running with --issues-tests does its
own filtering starting from the specs.
Moreover, this will allow --issues-tests to support the Buck integration, where
the specs/ directory is not populated after a run (although I suppose we could
also copy them from buck-out/ for InferPrint's benefit).
Reviewed By: jeremydubreil
Differential Revision: D4130851
fbshipit-source-id: 0457fba
Summary:
This makes our python code work (instead of crashing) when the source file
should be found not from the current directory (or absolute path), eg with
`infer --project-root .. -- clang -c hello.c`.
Reviewed By: jeremydubreil
Differential Revision: D4130802
fbshipit-source-id: 001f72d
Summary:
If the project root contains ".." then it doesn't work as expected, eg
infer --project-root .. -- clang hello.c
doesn't report at all. Now it works.
Reviewed By: jeremydubreil
Differential Revision: D4125489
fbshipit-source-id: 06b10ad
Summary: These functions are also called when the summary is guaranteed to exist. Enforcing this within the API
Reviewed By: cristianoc
Differential Revision: D4126839
fbshipit-source-id: 305b484
Summary: For some reason, `Specs.is_active` was re-loading from the specs table the summary that should already be in scope.
Reviewed By: cristianoc
Differential Revision: D4124693
fbshipit-source-id: c0e9113
Summary:
The Quandary-style traces are too general for checkers like SIOF.
This diff adds a "suffix abstraction" of the trace for analyses that just care about sinks.
To show how to use it, we add it to SIOF.
Note: this diff converts the domain, but isn't actually doing the fancier reporting yet.
That will come in a future diff.
Reviewed By: jvillard
Differential Revision: D4124881
fbshipit-source-id: 5b9fd07
Summary: Right now there is no test for compilation database integration. Add one
Reviewed By: jvillard
Differential Revision: D4118769
fbshipit-source-id: 5591de7
Summary:
This makes the tests depend on much fewer phony targets, thus reducing the need
to rerun the tests when nothing has changed.
Reviewed By: jberdine
Differential Revision: D4118457
fbshipit-source-id: 664b6e3
Summary:
Our default strategy for handling unknown code is to propagate taint from the actuals to the return value.
But for commonly-used methods like `StringBuilder.append` (used every time you do `+` with a string in Java), this doesn't work.
The taint should be propagated to both the receiver and the return value in these cases.
I'm considering a solution where we always propagate taint to the receiver of unknown functions in the future, but I am concerned about the performance.
So let's stick with a few special string cases for now.
Reviewed By: cristianoc
Differential Revision: D4124355
fbshipit-source-id: 5b2a232