Summary:
This change introduces a new binary, called `InferStatsAggregator`, that once invoked, aggregates
together all the stats generated by the single invocations of frontend/backend/reporting, that can
be used for performance measurements.
Reviewed By: jvillard
Differential Revision: D3317000
fbshipit-source-id: 61ec615
Summary:
End of the migration of .inferconfig-specific options into options accepted
both by .inferconfig and the CLI.
Reviewed By: jberdine
Differential Revision: D3304798
fbshipit-source-id: 14f6833
Summary:
Part of the migration of .inferconfig-specific options into options accepted
both by .inferconfig and the CLI.
This changes the behaviour of Infer in that we now create matchers eagerly
instead of lazily. I think it's ok because I suspect what's really important is
not laziness but memoisation, and thus laziness was just an implementation
detail. If I'm wrong please yell, it should be easy to revert to a lazy
behaviour if really needed.
Reviewed By: jberdine
Differential Revision: D3304792
fbshipit-source-id: 1ddde6d
Summary:
Part of the migration of .inferconfig-specific options into options accepted
both by .inferconfig and the CLI.
Reviewed By: jberdine
Differential Revision: D3304785
fbshipit-source-id: e0204e9
Summary:
Part of the migration of .inferconfig-specific options into options accepted
both by .inferconfig and the CLI.
Reviewed By: jberdine
Differential Revision: D3322508
fbshipit-source-id: 1820a9d
Summary:
Part of the migration of .inferconfig-specific options into options accepted
both by .inferconfig and the CLI.
Reviewed By: jberdine
Differential Revision: D3304784
fbshipit-source-id: 0c39b39
Summary:
Part of the migration of .inferconfig-specific options into options accepted
both by .inferconfig and the CLI.
Reviewed By: jberdine
Differential Revision: D3304783
fbshipit-source-id: 4a7ee6f
Summary:
Any option accepted by infer/InferAnalyze/... can now appear in
.inferconfig and will be interpreted accordingly. Options in .inferconfig
are overriden by both env vars parameters and command line
arguments.
To achieve this, we do a first round of parsing that only acts on the
flags necessary to find out where .inferconfig lives. Then we serialise
the contents of the json file into the format expected by command-line
arguments, and use a trick similar to the way we handle env variables to
interpret the json arguments.
Reviewed By: jberdine
Differential Revision: D3298379
fbshipit-source-id: 12b7d57
Summary:
If we see a read of a field f annotated with GuardedBy("mLock"), we spring into action.
What we do is look for some hpred `A.mLock |-> B` and return `B` as the "guarded-by object".
Once we have models for montitorenter/exit in place, `B.__inferIsLocked = true` will mean "lock held", and `B.__inferIsLocked = false` will mean "lock not held".
Reviewed By: jvillard
Differential Revision: D3316288
fbshipit-source-id: 8625e04
Summary:
Parse the inferconfig_home and project_root options in a separate phase
before other options. This enables using their values to e.g. find the
inferconfig file and process it prior to full option parsing.
Reviewed By: jvillard
Differential Revision: D3302143
fbshipit-source-id: a1f9175
Summary:
The checkers check was causing perf issues because it kept loading the json of
inferconfig. To prevent this from happening again, load json files inside
config.ml, and only export `Yojson.Basic.json Lazy.t` values to other modules.
Also move the list of checks disabled by default into config.ml for better
discoverability.
Reviewed By: jberdine
Differential Revision: D3293041
fbshipit-source-id: 4a38b26
Summary:
F for files, . for procedures, and a few more for developer mode.
Also add the crash message to the crash symbol, because if infer crashes we
want as much information as possible.
```
$ infer -- javac Hello.java
Starting analysis (Infer version v0.8.1-8e8c6fa)
legend:
"F" analyzing a file
"." analyzing a procedure
F..
Analyzed 1 file
Found 1 issue
Hello.java:13: error: NULL_DEREFERENCE
object s last assigned on line 12 could be null and is dereferenced at line 13
11. int test() {
12. String s = null;
13. > return s.length();
14. }
15. }
16.
Summary of the reports
NULL_DEREFERENCE: 1
$ infer -g -- javac Hello.java
...
Starting analysis (Infer version v0.8.1-8e8c6fa)
legend:
"F" analyzing a file
"." analyzing a procedure
"C" analyzer crashed
"T" timeout: procedure analysis took too much time
"S" timeout: procedure analysis took too many symbolic execution steps
"R" timeout: procedure analysis took too many recursive iterations
...
```
Reviewed By: sblackshear
Differential Revision: D3288081
fbshipit-source-id: becea34
Summary:
Reimplement command line options in preparation for uniformly passing
options from the top-level infer driver that invokes a build command
through the build system to the descendant infer processes.
All command line options of all executables are collected into Config,
and declared using a new CommandLineOption module that supports
maintining backward compatibility with the current command line
interface. Very few values representing command line options are
mutable now, as they are set once during parsing but are constant
thereafter. All ordering dependencies are contained within the
implementation of Config, and the implementation of Config is careful to
avoid unintended interactions and ordering dependencies between options.
Reviewed By: jvillard
Differential Revision: D3273345
fbshipit-source-id: 8e8c6fa
Summary:public
Report statistics on consumed time and memory in results_dir/perf_stats.json.
Reviewed By: martinoluca
Differential Revision: D3162381
fb-gh-sync-id: e802faa
fbshipit-source-id: e802faa
Summary:public
Refactor Utils.SymOp into a separate module, bringing the failure_kind
type and associated operations.
Reviewed By: cristianoc
Differential Revision: D3161640
fb-gh-sync-id: be3d7c9
fbshipit-source-id: be3d7c9
Summary:public
To ensure that e.g. Config.results_dir is not used before being set.
Reviewed By: cristianoc
Differential Revision: D3102724
fb-gh-sync-id: ced0974
fbshipit-source-id: ced0974
Summary:public
The reactive analysis starts from the set of changed files/procedures, and proceeds
reactively to analyze their dependencies.
This means that after every command, the set of changed files/procedures is reset.
With the --continue option, the capture is continued: all the files/procedures marked
as changed stay changed, plus any additional changes are recorded.
In addition to allowing to spread capture over several commands, the option also allows to separate capture and analysis in reactive mode, or to repeat the analysis.
Reviewed By: sblackshear
Differential Revision: D3046361
fb-gh-sync-id: b6e3797
shipit-source-id: b6e3797
Summary:public
Use the configuration file .inferconfig to model the library method that are considered expensive
Reviewed By: cristianoc
Differential Revision: D3045288
fb-gh-sync-id: e58d85c
shipit-source-id: e58d85c
Summary:public
Lazy dynamic dispatch handling works as follows:
Assuming a call of the form:
foo(a);
where the static type of `a` is `A`. If during the symbolic execution, the dynamic type of the variable `a` is `B` where `B <: A`, then we create on-demand a copy `foo(B)` of `foo(A)` where all the uses of the typed parameter `a` are replaced with a parameter of type `B`. Especially, if `foo` contains virtual call, say `get` where `a` is the receiver, then the call gets redirected to the overridden method in `B`, which simulates the runtime behavior of Java.
This lazy dynamic dispatch mode is only turn on for the tracing mode for now in order to avoid conflicts with sblackshear's approach for sound dynamic dispatch.
Reviewed By: sblackshear
Differential Revision: D2888922
fb-gh-sync-id: 3250c9e
shipit-source-id: 3250c9e
Summary:public
Remove back-end infrastructure that exists only when on-demand mode is disabled.
This, together with removing a few command-line options, sheds a lot of weight in the back-end.
No changes expected for on-demand mode.
Reviewed By: sblackshear
Differential Revision: D2960242
fb-gh-sync-id: 220d821
shipit-source-id: 220d821
Summary:public
Add command-line argument --reactive to enable reactive propagation mode.
When the mode is active, the files changed during compilation are detected, and the analysis propagates reactively starting from the modified files.
The reactive mode allows to analyze a subset of the files in a project and follow their dependencies, without storing the results of previous analyses (specs files). Captured files are preserved from previous runs of the analysis (for example, when the previous analysis was the initial capture), so the mode can be used repeatedly while changing code.
Reviewed By: jvillard
Differential Revision: D2931697
fb-gh-sync-id: 9d6dda0
shipit-source-id: 9d6dda0
Summary:
public
This diff cleans up the detection of assertion failures in C, C++ and Objective C which was previously hacked on top of the tracing mode for Java. The code is also generalized to detect any custom errors which can be defined using the `__infer_fail` builtin, and the case of assertion failure is now just the specific case of translating `assert` using `__infer_fail` directly in the clang frontend.
Reviewed By: jberdine
Differential Revision: D2786574
fb-gh-sync-id: dd1e1cf
Summary: public
This is an initial version of the Expensive checker which only report violations on direct calls. The main objective is to setup all the files for this new checker.
The next steps are:
1) run the checker in interprocedural mode
2) Save in the summary of a method foo() the annotation attribute Expensive if a direct callee of foo is annotated with Expensive
3) Check that Expensive is enforced by subtyping, i.e. check that non-expensive method cannot be overwritten by a method annotated with Expensive
Reviewed By: cristianoc
Differential Revision: D2629947
fb-gh-sync-id: 0e06f85
Summary: public
Adding a progress bar to the analysis phase to check progress.
The progress bar for the analysing procedures part is just printing dots at the moment and will be
improved soon when we do all the multithreading inside Ocaml.
There is also a no_progress_bar option in the scripts to hide it, for instance in CI.
Reviewed By: cristianoc
Differential Revision: D2625763
fb-gh-sync-id: daf6f96
Summary: @public
There was an inconsistency with the type of `stats.json` created by `inferlib.py` and InferAnalyze. This diff cleans up the thing and uses two different files to saves the statistics to clarify what gets created by the analysis, i.e. `proc_stats.json` and what gets created all the time `stats.json`.
Reviewed By: @sblackshear
Differential Revision: D2500517
Summary:
There's a lot of overlap between the representation of a proc desc and a spec summary. This diff moves all the data in common to the single record proc_attributes defined in Sil.
This gives a unified way of accessing most of the data carried by a procedure, whether it is contained in a proc desc or a spec. Also, it ensures that there is a single flow of information from proc desc to spec in the back-end, making sure that the information represented stays consistent.
Summary:
Procdesc comparison can be fragile because internal variable names
and source positions in a procedure can vary even if the procedure stays exactly the
same. This diff makes pdesc comparisons less fragile by defining structural comparsions
over instructions, nodes and expressions. These structural comparsions work by lazily
creating a mapping between names in the two procdesc's that and checking that the mapped
names are used consistently.
Dulma Churchill
Martino Luca
Jeremy Dubreil
Daiva Naudziuniene
Jules Villard
Sam Blackshear
Josh Berdine
Dino Distefano
Cristiano Calcagno
Andrzej Kotulski