|
|
|
NAME
|
|
|
|
infer-run - capture source files, analyze, and report
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
infer run [options]
|
|
|
|
infer [options] -- compile command
|
|
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
Calling "infer run [options]" is equivalent to performing the
|
|
|
|
following sequence of commands:
|
|
|
|
|
|
|
|
infer capture [options]
|
|
|
|
infer analyze [options]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
--censor-report +string
|
|
|
|
Specify a filter for issues to be censored by adding a
|
|
|
|
'censored_reason' field in the json report. Infer will not report
|
|
|
|
censored issues on the console output and in report.txt, but tools
|
|
|
|
that post-process the json report can take them into account. If
|
|
|
|
multiple filters are specified, they are applied in the order in
|
|
|
|
which they are specified. Each filter is applied to each issue
|
|
|
|
detected, and only issues which are accepted by all filters are
|
|
|
|
reported. Each filter is of the form:
|
|
|
|
`<issue_type_regex>:<filename_regex>:<reason_string>`. The first
|
|
|
|
two components are OCaml Str regular expressions, with an optional
|
|
|
|
`!` character prefix. If a regex has a `!` prefix, the polarity is
|
|
|
|
inverted, and the filter becomes a "blacklist" instead of a
|
|
|
|
"whitelist". Each filter is interpreted as an implication: an
|
|
|
|
issue matches if it does not match the `issue_type_regex` or if it
|
|
|
|
does match the `filename_regex`. The filenames that are tested by
|
|
|
|
the regex are relative to the `--project-root` directory. The
|
|
|
|
`<reason_string>` is a non-empty string used to explain why the
|
|
|
|
issue was filtered.
|
|
|
|
|
|
|
|
--debug,-g
|
|
|
|
Activates: Debug mode (also sets --debug-level 2,
|
make --debug option side-effect free
Summary:
I found it very confusing that running infer with --debug makes the
report to be different.
Intuitively, I expect (and I think majority of users would expect) that
`--debug` makes things more verbose (and potentially more slow / consuming
more memory and disk space), but does not change anything apart from it.
One pro of preserving existing behavior, pointed by jvillard:
- Suppose some check is experimental or disabled in the config. The
users expect the issue to be found, but it does not show up. They run
`infer --debug` to understand the behavior, and suddenly the issue shows
up.
I, hovewer, find this pro not important enough and potentially confusing
the users even more.
(If they want to investigate seriously, they can always use
--no-filtering, and there are a lot of cases when the issue does not
show up for others, much hard to undertand reasons, than the fact that
it is disabled).
Reviewed By: jvillard
Differential Revision: D17113750
fbshipit-source-id: 46cc93503
5 years ago
|
|
|
--developer-mode, --print-buckets, --print-types,
|
|
|
|
--reports-include-ml-loc, --no-only-cheap-debug, --trace-error,
|
|
|
|
--write-dotty, --write-html) (Conversely: --no-debug | -G)
|
|
|
|
|
|
|
|
--debug-level level
|
|
|
|
Debug level (sets --bo-debug level, --debug-level-analysis level,
|
|
|
|
--debug-level-capture level, --debug-level-linters level):
|
|
|
|
- 0: only basic debugging enabled
|
|
|
|
- 1: verbose debugging enabled
|
|
|
|
- 2: very verbose debugging enabled
|
|
|
|
|
|
|
|
--debug-level-analysis int
|
|
|
|
Debug level for the analysis. See --debug-level for accepted
|
|
|
|
values.
|
|
|
|
|
|
|
|
--debug-level-capture int
|
|
|
|
Debug level for the capture. See --debug-level for accepted
|
|
|
|
values.
|
|
|
|
|
|
|
|
--debug-level-linters int
|
|
|
|
Debug level for the linters. See --debug-level for accepted
|
|
|
|
values.
|
|
|
|
|
|
|
|
--fail-on-issue
|
|
|
|
Activates: Exit with error code 2 if Infer found something to
|
|
|
|
report (Conversely: --no-fail-on-issue)
|
|
|
|
|
|
|
|
--force-delete-results-dir
|
|
|
|
Activates: Do not refuse to delete the results directory if it
|
|
|
|
doesn't look like an infer results directory. (Conversely:
|
|
|
|
--no-force-delete-results-dir)
|
|
|
|
|
|
|
|
--force-integration command
|
|
|
|
Proceed as if the first argument after -- was command. Possible
|
|
|
|
values: ant, buck, gradle, gradlew, java, javac, cc, clang, gcc,
|
|
|
|
clang++, c++, g++, make, configure, cmake, waf, mvn, mvnw,
|
|
|
|
ndk-build, xcodebuild.
|
|
|
|
|
|
|
|
--help
|
|
|
|
Show this manual
|
|
|
|
|
|
|
|
--help-format { auto | groff | pager | plain }
|
|
|
|
Show this help in the specified format. auto sets the format to
|
|
|
|
plain if the environment variable TERM is "dumb" or undefined, and
|
|
|
|
to pager otherwise.
|
|
|
|
|
|
|
|
--help-full
|
|
|
|
Show this manual with all internal options in the INTERNAL OPTIONS
|
|
|
|
section
|
|
|
|
|
|
|
|
--print-logs
|
|
|
|
Activates: Also log messages to stdout and stderr (Conversely:
|
|
|
|
--no-print-logs)
|
|
|
|
|
|
|
|
--no-progress-bar,-P
|
|
|
|
Deactivates: Show a progress bar (Conversely: --progress-bar | -p)
|
|
|
|
|
|
|
|
--project-root,-C dir
|
|
|
|
Specify the root directory of the project
|
|
|
|
|
|
|
|
--no-report
|
|
|
|
Deactivates: Run the reporting phase once the analysis has
|
|
|
|
completed (Conversely: --report)
|
|
|
|
|
|
|
|
--report-blacklist-files-containing +string
|
|
|
|
Do not report any issues on files containing the specified string
|
|
|
|
|
|
|
|
--report-blacklist-path-regex +path_regex
|
|
|
|
Do not report any issues on files whose relative path matches the
|
|
|
|
specified OCaml regex, even if they match the whitelist specified
|
|
|
|
by --report-whitelist-path-regex
|
|
|
|
|
|
|
|
--report-force-relative-path
|
|
|
|
Activates: Force converting an absolute path to a relative path to
|
|
|
|
the root directory (Conversely: --no-report-force-relative-path)
|
|
|
|
|
|
|
|
--report-suppress-errors +error_name
|
|
|
|
do not report a type of errors
|
|
|
|
|
|
|
|
--report-whitelist-path-regex +path_regex
|
|
|
|
Report issues only on files whose relative path matches the
|
|
|
|
specified OCaml regex (and which do not match
|
|
|
|
--report-blacklist-path-regex)
|
|
|
|
|
|
|
|
--results-dir,-o dir
|
|
|
|
Write results and internal files in the specified directory
|
|
|
|
|
|
|
|
--skip-analysis-in-path +path_prefix_OCaml_regex
|
|
|
|
Ignore files whose path matches the given prefix (can be specified
|
|
|
|
multiple times)
|
|
|
|
|
|
|
|
--sqlite-cache-size int
|
|
|
|
SQLite cache size in pages (if positive) or kB (if negative),
|
|
|
|
follows formal of corresponding SQLite PRAGMA.
|
|
|
|
|
|
|
|
--sqlite-lock-timeout int
|
|
|
|
Timeout for SQLite results database operations, in milliseconds.
|
|
|
|
|
|
|
|
--sqlite-page-size int
|
|
|
|
SQLite page size in bytes, must be a power of two between 512 and
|
|
|
|
65536.
|
|
|
|
|
|
|
|
--version
|
|
|
|
Print version information and exit
|
|
|
|
|
|
|
|
--version-json
|
|
|
|
Print version information in json format and exit
|
|
|
|
|
|
|
|
-- Stop argument processing, use remaining arguments as a build
|
|
|
|
command
|
[buck] one buck mode datatype to rule them all
Summary:
This changes how we select amongst our (currently) 4 Buck integrations
for Java and clang, as well as how the user's choice is reflected by the
Config module.
The old command line interface is still supported but is now deprecated.
The changes in how to select each integration are:
- clang via "flavors", activated with `--flavors`, now with `--buck-clang`
- clang via "compilation DB", activated with `--buck-compilation-database`, unchanged
- Java via "genrule", activated with `--genrule-master-mode`, now with `--buck-java`
- Java "without genrules", used to be activated by *not specifying any other Buck mode*, unchanged
Instead of various `Config` flags corresponding to the previous CLI that
are allowed in any combination of `flavors`,
`buck_compilation_database`, `genrule_master_mode`, `Config` now exposes
a single `buck_mode` datatype. This allows, eg, `flavors` to override
`buck_compilation_database` if needed. It will also make it easier to
get rid of the old "Java without genrules" integration in a later diff
(see inline comments).
Reviewed By: ngorogiannis
Differential Revision: D19175686
fbshipit-source-id: 29b3831be
5 years ago
|
|
|
BUCK OPTIONS
|
|
|
|
--buck-blacklist +regex
|
|
|
|
Skip capture of files matched by the specified regular expression.
|
|
|
|
Only the clang, non-compilation-database Buck integration is supported, not Java.
|
|
|
|
|
|
|
|
--buck-targets-blacklist +regex
|
|
|
|
Skip capture of buck targets matched by the specified regular
|
[buck] one buck mode datatype to rule them all
Summary:
This changes how we select amongst our (currently) 4 Buck integrations
for Java and clang, as well as how the user's choice is reflected by the
Config module.
The old command line interface is still supported but is now deprecated.
The changes in how to select each integration are:
- clang via "flavors", activated with `--flavors`, now with `--buck-clang`
- clang via "compilation DB", activated with `--buck-compilation-database`, unchanged
- Java via "genrule", activated with `--genrule-master-mode`, now with `--buck-java`
- Java "without genrules", used to be activated by *not specifying any other Buck mode*, unchanged
Instead of various `Config` flags corresponding to the previous CLI that
are allowed in any combination of `flavors`,
`buck_compilation_database`, `genrule_master_mode`, `Config` now exposes
a single `buck_mode` datatype. This allows, eg, `flavors` to override
`buck_compilation_database` if needed. It will also make it easier to
get rid of the old "Java without genrules" integration in a later diff
(see inline comments).
Reviewed By: ngorogiannis
Differential Revision: D19175686
fbshipit-source-id: 29b3831be
5 years ago
|
|
|
expression. Only valid for --buck-compilation-database.
|
|
|
|
CLANG OPTIONS
|
|
|
|
--compute-analytics
|
|
|
|
Activates: Emit analytics as info-level issues, like component kit
|
|
|
|
line count and component kit file cyclomatic complexity
|
|
|
|
(Conversely: --no-compute-analytics)
|
|
|
|
JAVA OPTIONS
|
|
|
|
--capture-blacklist regex
|
|
|
|
Skip capture of files matched by the specified OCaml regular
|
|
|
|
expression (only supported by the javac integration for now).
|
|
|
|
|
|
|
|
|
|
|
|
ENVIRONMENT
|
|
|
|
INFER_ARGS, INFERCONFIG, INFER_STRICT_MODE
|
|
|
|
See the ENVIRONMENT section in the manual of infer(1).
|
|
|
|
|
|
|
|
FILES
|
|
|
|
.inferconfig
|
|
|
|
See the FILES section in the manual of infer(1).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SEE ALSO
|
|
|
|
infer-analyze(1), infer-capture(1), infer-report(1)
|
|
|
|
|
|
|
|
|
|
|
|
|