pghs975uc
/
infer_clone
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '1b8305d1e1'
${ noResults }
infer_clone/infer/man/man1/infer-report.txt

354 lines
17 KiB
Raw Normal View History Unescape

[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
NAME
infer-report - compute and manipulate infer results
SYNOPSIS
infer report [options] [file.specs...]
DESCRIPTION
Read, convert, and print .specs files in the results directory. Each
spec is printed to standard output unless option -q is used.
If no specs file are passed on the command line, process all the
.specs in the results directory.
OPTIONS
[config] Rename `filter-report` command to `censor-report` and stop reporting them on console and bugs.txt Summary: - Rename `filter-report` command to `censor-report`and update comments - Stop reporting censored issues on the console and in `bugs.txt` Reviewed By: jvillard Differential Revision: D16540525 fbshipit-source-id: f5f7dcea3
5 years ago
--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 bugs.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.
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--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,
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--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
[help] scrub default values in the checked-in version of the manuals Summary: The default values of config options can sometimes depend on build-time configuration values. This makes checking that the manuals "remain the same" trickier as the manuals can be different depending on the platform. This removes *all* default values from the checked-in manuals. We could be more fine-grained and scrub only the values that are susceptible to change but for now this is probably good enough. This is done by implementing new options `--help-scrubbed` and `--help-scrubbed-full` and using these in our tests instead of `--help` and `--help-full` (which remain unaffected). Also don't wrap the default values in `$(i,...)` anymore because the defaults can trigger line breaks and then the man page is ill-formatted because that format is stupid. Reviewed By: mityal Differential Revision: D16543779 fbshipit-source-id: bc929ff8c
5 years ago
values.
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--debug-level-capture int
Debug level for the capture. See --debug-level for accepted
[help] scrub default values in the checked-in version of the manuals Summary: The default values of config options can sometimes depend on build-time configuration values. This makes checking that the manuals "remain the same" trickier as the manuals can be different depending on the platform. This removes *all* default values from the checked-in manuals. We could be more fine-grained and scrub only the values that are susceptible to change but for now this is probably good enough. This is done by implementing new options `--help-scrubbed` and `--help-scrubbed-full` and using these in our tests instead of `--help` and `--help-full` (which remain unaffected). Also don't wrap the default values in `$(i,...)` anymore because the defaults can trigger line breaks and then the man page is ill-formatted because that format is stupid. Reviewed By: mityal Differential Revision: D16543779 fbshipit-source-id: bc929ff8c
5 years ago
values.
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--debug-level-linters int
Debug level for the linters. See --debug-level for accepted
[help] scrub default values in the checked-in version of the manuals Summary: The default values of config options can sometimes depend on build-time configuration values. This makes checking that the manuals "remain the same" trickier as the manuals can be different depending on the platform. This removes *all* default values from the checked-in manuals. We could be more fine-grained and scrub only the values that are susceptible to change but for now this is probably good enough. This is done by implementing new options `--help-scrubbed` and `--help-scrubbed-full` and using these in our tests instead of `--help` and `--help-full` (which remain unaffected). Also don't wrap the default values in `$(i,...)` anymore because the defaults can trigger line breaks and then the man page is ill-formatted because that format is stupid. Reviewed By: mityal Differential Revision: D16543779 fbshipit-source-id: bc929ff8c
5 years ago
values.
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
[filtering/dedup] add deduplicate flag and disambiguate filtering Summary: The documentation and uses of filtering disagree. One typical usage is deduplication. Split that where obvious, add comments where not obvious, and leave alone when obviously unrelated to deduplication. Reviewed By: mityal Differential Revision: D17715329 fbshipit-source-id: ec757927b
5 years ago
--no-deduplicate
Deactivates: Apply issue-specific deduplication during analysis
and/or reporting. (Conversely: --deduplicate)
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--differential-filter-files string
Specify the file containing the list of source files for which a
differential report is desired. Source files should be specified
relative to project root or be absolute
--disable-issue-type +issue_type
Do not show reports coming from this type of issue. Each checker
can report a range of issue types. This option provides
fine-grained filtering over which types of issue should be
reported once the checkers have run. In particular, note that
disabling issue types does not make the corresponding checker not
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
run. Available issue types are as follows:
[cost] Refactor cost issue types and enable detecting allocation complexity increase on cold start Summary: - Add allocation costs to `costs-report.json` and enable diffing over allocation costs. - Also, let's be more consistent and modular in naming our cost issues. - introduce a generic issue type `X_TIME_COMPLEXITY_INCREASE` where `X` can be one of the cost kinds. If the function is on the cold start, issue can have the `COLD_START` suffix. Similarly for infinite/zero/expensive calls. - Change `PERFORMANCE_VARIATION` -> `EXECUTION_TIME_COMPLEXITY_INCREASE` - Add new issue type for `ALLOCATION_COMPLEXITY_INCREASE_COLD_START` which will be enabled by default - Refactor cost issues to be more modular and succinct. This also makes addition of a new cost kind very easy by adding the kind into the `enabled_cost_kinds` list in `CostKind.ml` Reviewed By: mbouaziz Differential Revision: D15822681 fbshipit-source-id: cf89ece59
6 years ago
ALLOCATION_COMPLEXITY_INCREASE (enabled by default),
ALLOCATION_COMPLEXITY_INCREASE_COLD_START (enabled by default),
[cost] Introduce cost issue types for functions on UI Thread Summary: Let's introduce a set of new cost analysis issue types that are raised when the function is statically determined to run on the UI thread. For this, we rely on the existing `runs_on_ui_thread` check that is developed for RacerD. We also update the cost summary and `jsonbug.cost_item` to include whether a method is on the ui thread so that we don't repeatedly compute this at diff time for complexity increase issues. Note that `*_UI_THREAD` cost issues are assumed to be more strict than `*_COLD_START` reports at the moment. Next, we can also consider adding a new issue type that combines both such as `*_UI_THREAD_AND_COLD_START` (i.e. for methods that are both on cold start and run on ui thread). Reviewed By: ngorogiannis Differential Revision: D18428408 fbshipit-source-id: f18805716
5 years ago
ALLOCATION_COMPLEXITY_INCREASE_UI_THREAD (enabled by default),
[cost] Refactor cost issue types and enable detecting allocation complexity increase on cold start Summary: - Add allocation costs to `costs-report.json` and enable diffing over allocation costs. - Also, let's be more consistent and modular in naming our cost issues. - introduce a generic issue type `X_TIME_COMPLEXITY_INCREASE` where `X` can be one of the cost kinds. If the function is on the cold start, issue can have the `COLD_START` suffix. Similarly for infinite/zero/expensive calls. - Change `PERFORMANCE_VARIATION` -> `EXECUTION_TIME_COMPLEXITY_INCREASE` - Add new issue type for `ALLOCATION_COMPLEXITY_INCREASE_COLD_START` which will be enabled by default - Refactor cost issues to be more modular and succinct. This also makes addition of a new cost kind very easy by adding the kind into the `enabled_cost_kinds` list in `CostKind.ml` Reviewed By: mbouaziz Differential Revision: D15822681 fbshipit-source-id: cf89ece59
6 years ago
ANALYSIS_STOPS (disabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
ARRAY_OUT_OF_BOUNDS_L1 (disabled by default),
ARRAY_OUT_OF_BOUNDS_L2 (disabled by default),
ARRAY_OUT_OF_BOUNDS_L3 (disabled by default),
Abduction_case_not_implemented (enabled by default),
Array_of_pointsto (enabled by default),
Assert_failure (enabled by default),
[biabduction] Rename use_after_free to avoid name clash with Pulse Summary: Use_after_free was used both for biabduction and pulse, and the biabduction version is blacklisted by default. As a result, the Pulse version was also disabled unintentionally. This changes the name of the old use_after_free so that now we can get use_after_free bugs whenever pulse is enabled. Reviewed By: skcho Differential Revision: D17182687 fbshipit-source-id: 539ca69de
5 years ago
BIABD_USE_AFTER_FREE (enabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
BUFFER_OVERRUN_L1 (enabled by default),
BUFFER_OVERRUN_L2 (enabled by default),
BUFFER_OVERRUN_L3 (enabled by default),
BUFFER_OVERRUN_L4 (disabled by default),
BUFFER_OVERRUN_L5 (disabled by default),
BUFFER_OVERRUN_R2 (enabled by default),
BUFFER_OVERRUN_S2 (enabled by default),
BUFFER_OVERRUN_U5 (disabled by default),
Bad_footprint (enabled by default),
CHECKERS_ALLOCATES_MEMORY (enabled by default),
CHECKERS_ANNOTATION_REACHABILITY_ERROR (enabled by default),
CHECKERS_CALLS_EXPENSIVE_METHOD (enabled by default),
CHECKERS_EXPENSIVE_OVERRIDES_UNANNOTATED (enabled by default),
CHECKERS_FRAGMENT_RETAINS_VIEW (enabled by default),
CHECKERS_IMMUTABLE_CAST (enabled by default),
CHECKERS_PRINTF_ARGS (enabled by default),
CLASS_CAST_EXCEPTION (disabled by default),
CLASS_LOAD (enabled by default),
COMPARING_FLOAT_FOR_EQUALITY (enabled by default),
COMPONENT_FACTORY_FUNCTION (enabled by default),
COMPONENT_FILE_CYCLOMATIC_COMPLEXITY (enabled by default),
COMPONENT_FILE_LINE_COUNT (enabled by default),
COMPONENT_INITIALIZER_WITH_SIDE_EFFECTS (enabled by default),
COMPONENT_WITH_MULTIPLE_FACTORY_METHODS (enabled by default),
COMPONENT_WITH_UNCONVENTIONAL_SUPERCLASS (enabled by default),
CONDITION_ALWAYS_FALSE (disabled by default),
CONDITION_ALWAYS_TRUE (disabled by default),
[pulse] report dereference of NULL and constants Summary: Note: Disabled by default. Having some support for values, we can report when a null or constant value is being dereferenced. The particularity here is that we don't report when 0 is a possible value for the address, or even if we know that the value of the address can only be 0 in that branch! Instead, we allow ourselves to report only when we the address has been *set* to NULL (or any constant). This is in line with how pulse deals with other issues: only report when 1. we see an address become invalid, and 2. we see the same address be used later on Reviewed By: skcho Differential Revision: D17665468 fbshipit-source-id: f1ccf94cf
5 years ago
CONSTANT_ADDRESS_DEREFERENCE (disabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
CREATE_INTENT_FROM_URI (enabled by default),
CROSS_SITE_SCRIPTING (enabled by default),
Cannot_star (enabled by default),
Codequery (enabled by default),
DANGLING_POINTER_DEREFERENCE (disabled by default),
DEADLOCK (enabled by default),
DEAD_STORE (enabled by default),
DEALLOCATE_STACK_VARIABLE (enabled by default),
DEALLOCATE_STATIC_MEMORY (enabled by default),
DEALLOCATION_MISMATCH (enabled by default),
DIVIDE_BY_ZERO (disabled by default),
DO_NOT_REPORT (enabled by default),
EMPTY_VECTOR_ACCESS (enabled by default),
ERADICATE_CONDITION_REDUNDANT (enabled by default),
ERADICATE_CONDITION_REDUNDANT_NONNULL (enabled by default),
ERADICATE_FIELD_NOT_INITIALIZED (enabled by default),
ERADICATE_FIELD_NOT_NULLABLE (enabled by default),
ERADICATE_FIELD_OVER_ANNOTATED (enabled by default),
ERADICATE_INCONSISTENT_SUBCLASS_PARAMETER_ANNOTATION (enabled
by default),
ERADICATE_INCONSISTENT_SUBCLASS_RETURN_ANNOTATION (enabled by
default),
ERADICATE_NULLABLE_DEREFERENCE (enabled by default),
ERADICATE_PARAMETER_NOT_NULLABLE (enabled by default),
ERADICATE_RETURN_NOT_NULLABLE (enabled by default),
ERADICATE_RETURN_OVER_ANNOTATED (enabled by default),
[cost] Refactor cost issue types and enable detecting allocation complexity increase on cold start Summary: - Add allocation costs to `costs-report.json` and enable diffing over allocation costs. - Also, let's be more consistent and modular in naming our cost issues. - introduce a generic issue type `X_TIME_COMPLEXITY_INCREASE` where `X` can be one of the cost kinds. If the function is on the cold start, issue can have the `COLD_START` suffix. Similarly for infinite/zero/expensive calls. - Change `PERFORMANCE_VARIATION` -> `EXECUTION_TIME_COMPLEXITY_INCREASE` - Add new issue type for `ALLOCATION_COMPLEXITY_INCREASE_COLD_START` which will be enabled by default - Refactor cost issues to be more modular and succinct. This also makes addition of a new cost kind very easy by adding the kind into the `enabled_cost_kinds` list in `CostKind.ml` Reviewed By: mbouaziz Differential Revision: D15822681 fbshipit-source-id: cf89ece59
6 years ago
EXECUTION_TIME_COMPLEXITY_INCREASE (enabled by default),
EXECUTION_TIME_COMPLEXITY_INCREASE_COLD_START (enabled by
[cost] Introduce cost issue types for functions on UI Thread Summary: Let's introduce a set of new cost analysis issue types that are raised when the function is statically determined to run on the UI thread. For this, we rely on the existing `runs_on_ui_thread` check that is developed for RacerD. We also update the cost summary and `jsonbug.cost_item` to include whether a method is on the ui thread so that we don't repeatedly compute this at diff time for complexity increase issues. Note that `*_UI_THREAD` cost issues are assumed to be more strict than `*_COLD_START` reports at the moment. Next, we can also consider adding a new issue type that combines both such as `*_UI_THREAD_AND_COLD_START` (i.e. for methods that are both on cold start and run on ui thread). Reviewed By: ngorogiannis Differential Revision: D18428408 fbshipit-source-id: f18805716
5 years ago
default),
EXECUTION_TIME_COMPLEXITY_INCREASE_UI_THREAD (enabled by
[cost] Refactor cost issue types and enable detecting allocation complexity increase on cold start Summary: - Add allocation costs to `costs-report.json` and enable diffing over allocation costs. - Also, let's be more consistent and modular in naming our cost issues. - introduce a generic issue type `X_TIME_COMPLEXITY_INCREASE` where `X` can be one of the cost kinds. If the function is on the cold start, issue can have the `COLD_START` suffix. Similarly for infinite/zero/expensive calls. - Change `PERFORMANCE_VARIATION` -> `EXECUTION_TIME_COMPLEXITY_INCREASE` - Add new issue type for `ALLOCATION_COMPLEXITY_INCREASE_COLD_START` which will be enabled by default - Refactor cost issues to be more modular and succinct. This also makes addition of a new cost kind very easy by adding the kind into the `enabled_cost_kinds` list in `CostKind.ml` Reviewed By: mbouaziz Differential Revision: D15822681 fbshipit-source-id: cf89ece59
6 years ago
default),
EXPENSIVE_ALLOCATION (disabled by default),
EXPENSIVE_ALLOCATION_COLD_START (disabled by default),
[cost] Introduce cost issue types for functions on UI Thread Summary: Let's introduce a set of new cost analysis issue types that are raised when the function is statically determined to run on the UI thread. For this, we rely on the existing `runs_on_ui_thread` check that is developed for RacerD. We also update the cost summary and `jsonbug.cost_item` to include whether a method is on the ui thread so that we don't repeatedly compute this at diff time for complexity increase issues. Note that `*_UI_THREAD` cost issues are assumed to be more strict than `*_COLD_START` reports at the moment. Next, we can also consider adding a new issue type that combines both such as `*_UI_THREAD_AND_COLD_START` (i.e. for methods that are both on cold start and run on ui thread). Reviewed By: ngorogiannis Differential Revision: D18428408 fbshipit-source-id: f18805716
5 years ago
EXPENSIVE_ALLOCATION_UI_THREAD (disabled by default),
[cost] Refactor cost issue types and enable detecting allocation complexity increase on cold start Summary: - Add allocation costs to `costs-report.json` and enable diffing over allocation costs. - Also, let's be more consistent and modular in naming our cost issues. - introduce a generic issue type `X_TIME_COMPLEXITY_INCREASE` where `X` can be one of the cost kinds. If the function is on the cold start, issue can have the `COLD_START` suffix. Similarly for infinite/zero/expensive calls. - Change `PERFORMANCE_VARIATION` -> `EXECUTION_TIME_COMPLEXITY_INCREASE` - Add new issue type for `ALLOCATION_COMPLEXITY_INCREASE_COLD_START` which will be enabled by default - Refactor cost issues to be more modular and succinct. This also makes addition of a new cost kind very easy by adding the kind into the `enabled_cost_kinds` list in `CostKind.ml` Reviewed By: mbouaziz Differential Revision: D15822681 fbshipit-source-id: cf89ece59
6 years ago
EXPENSIVE_EXECUTION_TIME (disabled by default),
EXPENSIVE_EXECUTION_TIME_COLD_START (disabled by default),
[cost] Introduce cost issue types for functions on UI Thread Summary: Let's introduce a set of new cost analysis issue types that are raised when the function is statically determined to run on the UI thread. For this, we rely on the existing `runs_on_ui_thread` check that is developed for RacerD. We also update the cost summary and `jsonbug.cost_item` to include whether a method is on the ui thread so that we don't repeatedly compute this at diff time for complexity increase issues. Note that `*_UI_THREAD` cost issues are assumed to be more strict than `*_COLD_START` reports at the moment. Next, we can also consider adding a new issue type that combines both such as `*_UI_THREAD_AND_COLD_START` (i.e. for methods that are both on cold start and run on ui thread). Reviewed By: ngorogiannis Differential Revision: D18428408 fbshipit-source-id: f18805716
5 years ago
EXPENSIVE_EXECUTION_TIME_UI_THREAD (disabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
EXPENSIVE_LOOP_INVARIANT_CALL (enabled by default),
EXPOSED_INSECURE_INTENT_HANDLING (enabled by default),
Failure_exe (enabled by default),
GLOBAL_VARIABLE_INITIALIZED_WITH_FUNCTION_OR_METHOD_CALL
(disabled by default),
GRAPHQL_FIELD_ACCESS (enabled by default),
GUARDEDBY_VIOLATION (enabled by default),
[pulse][impurity] Use pulse for detecting impurity Summary: Introduce a new experimental checker (`--impurity`) that detects impurity information, tracking which parameters and global variables of a function are modified. The checker relies on Pulse to detect how the state changes: it traverses the pre and post pairs starting from the parameter/global variable and finds where the pre and post heaps diverge. At diversion points, we expect to see WrittenTo/Invalid attributes containing a trace of how the address was modified. We use these to construct the trace of impurity. This checker is a complement to the purity checker that exists mainly for Java (and used for cost and loop-hoisting analyses). The aim of this new experimental checker is to rely on Pulse's precise memory treatment and come up with a more precise im(purity) analysis. To distinguish the two checkers, we introduce a new issue type `IMPURE_FUNCTION` that reports when a function is impure, rather than when it is pure (as in the purity checker). TODO: - improve the analysis to rely on impurity information of external library calls. Currently, all library calls are assumed to be nops, hence pure. - de-entangle Pulse reporting from analysis. Reviewed By: skcho Differential Revision: D17051567 fbshipit-source-id: 5e10afb4f
5 years ago
IMPURE_FUNCTION (enabled by default),
[inefficient-keyset-iterator] New checker for finding inefficient keySet iterator Summary: This is a simple checker that identifies inefficient uses of `keySet` iterator where (not only the key but also) the value is accessed via `get(key)`. It is more efficient to use `entrySet` iterator which already returns both key-value pairs. This optimization would get rid of many extra lookups which can be expensive. We simply traverse the CFG starting from the loop head upwards and pick up the map that is iterated over. Then, we check in the loop nodes if there is a call to `get(...)` over this map. If, so we report. Reviewed By: ngorogiannis Differential Revision: D15737779 fbshipit-source-id: 702465b4e
6 years ago
INEFFICIENT_KEYSET_ITERATOR (enabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
INFERBO_ALLOC_IS_BIG (enabled by default),
INFERBO_ALLOC_IS_NEGATIVE (enabled by default),
INFERBO_ALLOC_IS_ZERO (enabled by default),
INFERBO_ALLOC_MAY_BE_BIG (enabled by default),
INFERBO_ALLOC_MAY_BE_NEGATIVE (enabled by default),
[cost] Refactor cost issue types and enable detecting allocation complexity increase on cold start Summary: - Add allocation costs to `costs-report.json` and enable diffing over allocation costs. - Also, let's be more consistent and modular in naming our cost issues. - introduce a generic issue type `X_TIME_COMPLEXITY_INCREASE` where `X` can be one of the cost kinds. If the function is on the cold start, issue can have the `COLD_START` suffix. Similarly for infinite/zero/expensive calls. - Change `PERFORMANCE_VARIATION` -> `EXECUTION_TIME_COMPLEXITY_INCREASE` - Add new issue type for `ALLOCATION_COMPLEXITY_INCREASE_COLD_START` which will be enabled by default - Refactor cost issues to be more modular and succinct. This also makes addition of a new cost kind very easy by adding the kind into the `enabled_cost_kinds` list in `CostKind.ml` Reviewed By: mbouaziz Differential Revision: D15822681 fbshipit-source-id: cf89ece59
6 years ago
INFINITE_ALLOCATION (disabled by default),
INFINITE_EXECUTION_TIME (disabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
INHERENTLY_DANGEROUS_FUNCTION (enabled by default),
INSECURE_INTENT_HANDLING (enabled by default),
INTEGER_OVERFLOW_L1 (enabled by default),
INTEGER_OVERFLOW_L2 (enabled by default),
INTEGER_OVERFLOW_L5 (disabled by default),
INTEGER_OVERFLOW_R2 (enabled by default),
INTEGER_OVERFLOW_U5 (disabled by default),
INTERFACE_NOT_THREAD_SAFE (enabled by default),
[invariant-call] Disable issue type Summary: We only care about expensive invariant calls. Let's disable the usual one since it is not used and there is no point filling up our dbs. Reviewed By: dulmarod Differential Revision: D18298530 fbshipit-source-id: 7a933c8da
5 years ago
INVARIANT_CALL (disabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
IVAR_NOT_NULL_CHECKED (enabled by default),
Internal_error (enabled by default),
JAVASCRIPT_INJECTION (enabled by default),
[lockless] detect lock acquisitions from methods annotated @Lockless Summary: Catch methods annotated (transitively) as `Lockless` which acquire a lock (transitively). Reviewed By: artempyanykh Differential Revision: D17396575 fbshipit-source-id: f9f2cfc1b
5 years ago
LOCKLESS_VIOLATION (enabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
LOCK_CONSISTENCY_VIOLATION (enabled by default),
LOGGING_PRIVATE_DATA (enabled by default),
Leak_after_array_abstraction (enabled by default),
Leak_in_footprint (enabled by default),
MEMORY_LEAK (enabled by default),
MISSING_REQUIRED_PROP (enabled by default),
[self in block] Add a new checker to detect correct uses of when ObjC blocks capture self. Reviewed By: skcho Differential Revision: D18245267 fbshipit-source-id: 6e3f1a7f7
5 years ago
MIXED_SELF_WEAKSELF (enabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
MUTABLE_LOCAL_VARIABLE_IN_COMPONENT_FILE (enabled by default),
Missing_fld (enabled by default),
[pulse] report dereference of NULL and constants Summary: Note: Disabled by default. Having some support for values, we can report when a null or constant value is being dereferenced. The particularity here is that we don't report when 0 is a possible value for the address, or even if we know that the value of the address can only be 0 in that branch! Instead, we allow ourselves to report only when we the address has been *set* to NULL (or any constant). This is in line with how pulse deals with other issues: only report when 1. we see an address become invalid, and 2. we see the same address be used later on Reviewed By: skcho Differential Revision: D17665468 fbshipit-source-id: f1ccf94cf
5 years ago
NULLPTR_DEREFERENCE (disabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
NULLSAFE_FIELD_NOT_NULLABLE (enabled by default),
NULLSAFE_NULLABLE_DEREFERENCE (enabled by default),
NULL_DEREFERENCE (enabled by default),
NULL_TEST_AFTER_DEREFERENCE (disabled by default),
PARAMETER_NOT_NULL_CHECKED (enabled by default),
POINTER_SIZE_MISMATCH (enabled by default),
PRECONDITION_NOT_FOUND (enabled by default),
PRECONDITION_NOT_MET (enabled by default),
PREMATURE_NIL_TERMINATION_ARGUMENT (enabled by default),
PURE_FUNCTION (enabled by default),
QUANDARY_TAINT_ERROR (enabled by default),
REGISTERED_OBSERVER_BEING_DEALLOCATED (enabled by default),
RESOURCE_LEAK (enabled by default),
RETAIN_CYCLE (enabled by default),
RETURN_EXPRESSION_REQUIRED (enabled by default),
RETURN_STATEMENT_MISSING (enabled by default),
RETURN_VALUE_IGNORED (disabled by default),
SHELL_INJECTION (enabled by default),
SHELL_INJECTION_RISK (enabled by default),
SKIP_FUNCTION (enabled by default),
SKIP_POINTER_DEREFERENCE (enabled by default),
SQL_INJECTION (enabled by default),
SQL_INJECTION_RISK (enabled by default),
STACK_VARIABLE_ADDRESS_ESCAPE (disabled by default),
STARVATION (enabled by default),
STATIC_INITIALIZATION_ORDER_FIASCO (enabled by default),
STRICT_MODE_VIOLATION (enabled by default),
[self in block] Add a check for strongSelf not checked for null Summary: The variable strongSelf, because it is equal to a weak captured pointer, needs to be checked for null before being used, otherwise it could be null by the time the block is executed. Added this check to the SelfInBlock checker, and removed it from biabduction. We want to migrate all the objc checks from biabduction, so it will be easier to change and faster and more reliable. Moreover, this check is more general, it will flag any use of unchecked strongSelf, not just a dereference. Reviewed By: skcho Differential Revision: D18403849 fbshipit-source-id: a9cf5d80b
5 years ago
STRONG_SELF_NOT_CHECKED (enabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
Symexec_memory_error (enabled by default),
TAINTED_BUFFER_ACCESS (enabled by default),
TAINTED_MEMORY_ALLOCATION (enabled by default),
THREAD_SAFETY_VIOLATION (enabled by default),
[topl] Simple error reporting. Reviewed By: jvillard Differential Revision: D15875271 fbshipit-source-id: 148206be9
6 years ago
TOPL_ERROR (enabled by default),
[CLI] print all available issue types Summary: Previously there was no way of getting that list from the manual. Reviewed By: jeremydubreil Differential Revision: D15158598 fbshipit-source-id: 1705ed59d
6 years ago
UNARY_MINUS_APPLIED_TO_UNSIGNED_EXPRESSION (disabled by
default),
UNINITIALIZED_VALUE (enabled by default),
UNREACHABLE_CODE (enabled by default),
UNSAFE_GUARDED_BY_ACCESS (enabled by default),
UNTRUSTED_BUFFER_ACCESS (disabled by default),
UNTRUSTED_DESERIALIZATION (enabled by default),
UNTRUSTED_DESERIALIZATION_RISK (enabled by default),
UNTRUSTED_ENVIRONMENT_CHANGE_RISK (enabled by default),
UNTRUSTED_FILE (enabled by default),
UNTRUSTED_FILE_RISK (enabled by default),
UNTRUSTED_HEAP_ALLOCATION (disabled by default),
UNTRUSTED_INTENT_CREATION (enabled by default),
UNTRUSTED_URL_RISK (enabled by default),
UNTRUSTED_VARIABLE_LENGTH_ARRAY (enabled by default),
USER_CONTROLLED_SQL_RISK (enabled by default),
USE_AFTER_DELETE (enabled by default),
USE_AFTER_FREE (enabled by default),
USE_AFTER_LIFETIME (enabled by default),
Unknown_proc (enabled by default),
VECTOR_INVALIDATION (enabled by default),
Wrong_argument_number (enabled by default),
[cost] Refactor cost issue types and enable detecting allocation complexity increase on cold start Summary: - Add allocation costs to `costs-report.json` and enable diffing over allocation costs. - Also, let's be more consistent and modular in naming our cost issues. - introduce a generic issue type `X_TIME_COMPLEXITY_INCREASE` where `X` can be one of the cost kinds. If the function is on the cold start, issue can have the `COLD_START` suffix. Similarly for infinite/zero/expensive calls. - Change `PERFORMANCE_VARIATION` -> `EXECUTION_TIME_COMPLEXITY_INCREASE` - Add new issue type for `ALLOCATION_COMPLEXITY_INCREASE_COLD_START` which will be enabled by default - Refactor cost issues to be more modular and succinct. This also makes addition of a new cost kind very easy by adding the kind into the `enabled_cost_kinds` list in `CostKind.ml` Reviewed By: mbouaziz Differential Revision: D15822681 fbshipit-source-id: cf89ece59
6 years ago
ZERO_ALLOCATION (disabled by default),
ZERO_EXECUTION_TIME (disabled by default).
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--enable-issue-type +issue_type
Show reports coming from this type of issue. By default, all issue
types are enabled except the ones listed in --disable-issue-type.
Note that enabling issue types does not make the corresponding
checker run; see individual checker options to turn them on or
off.
--no-filtering,-F
Deactivates: Do not show the experimental and blacklisted issue
types (Conversely: --filtering | -f)
--from-json-report report.json
Load analysis results from a report file (default is to load the
results from the specs files generated by the analysis).
--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
[help] scrub default values in the checked-in version of the manuals Summary: The default values of config options can sometimes depend on build-time configuration values. This makes checking that the manuals "remain the same" trickier as the manuals can be different depending on the platform. This removes *all* default values from the checked-in manuals. We could be more fine-grained and scrub only the values that are susceptible to change but for now this is probably good enough. This is done by implementing new options `--help-scrubbed` and `--help-scrubbed-full` and using these in our tests instead of `--help` and `--help-full` (which remain unaffected). Also don't wrap the default values in `$(i,...)` anymore because the defaults can trigger line breaks and then the man page is ill-formatted because that format is stupid. Reviewed By: mityal Differential Revision: D16543779 fbshipit-source-id: bc929ff8c
5 years ago
to pager otherwise.
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--help-full
Show this manual with all internal options in the INTERNAL OPTIONS
section
--issues-fields ,-separated sequence of { bug_type | bucket |
[infer] remove the visibility field from the Infer JSON report Reviewed By: mbouaziz Differential Revision: D9689136 fbshipit-source-id: fabdb3ffc
6 years ago
qualifier | severity | line | column | procedure |
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
procedure_start_line | file | bug_trace | key | hash | line_offset |
qualifier_contains_potential_exception_note }
[help] scrub default values in the checked-in version of the manuals Summary: The default values of config options can sometimes depend on build-time configuration values. This makes checking that the manuals "remain the same" trickier as the manuals can be different depending on the platform. This removes *all* default values from the checked-in manuals. We could be more fine-grained and scrub only the values that are susceptible to change but for now this is probably good enough. This is done by implementing new options `--help-scrubbed` and `--help-scrubbed-full` and using these in our tests instead of `--help` and `--help-full` (which remain unaffected). Also don't wrap the default values in `$(i,...)` anymore because the defaults can trigger line breaks and then the man page is ill-formatted because that format is stupid. Reviewed By: mityal Differential Revision: D16543779 fbshipit-source-id: bc929ff8c
5 years ago
Fields to emit with --issues-tests
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--issues-tests file
Write a list of issues in a format suitable for tests to file
--issues-txt file
Write a list of issues in text format to file (default:
infer-out/bugs.txt)
--print-logs
Activates: Also log messages to stdout and stderr (Conversely:
--no-print-logs)
--project-root,-C dir
[help] scrub default values in the checked-in version of the manuals Summary: The default values of config options can sometimes depend on build-time configuration values. This makes checking that the manuals "remain the same" trickier as the manuals can be different depending on the platform. This removes *all* default values from the checked-in manuals. We could be more fine-grained and scrub only the values that are susceptible to change but for now this is probably good enough. This is done by implementing new options `--help-scrubbed` and `--help-scrubbed-full` and using these in our tests instead of `--help` and `--help-full` (which remain unaffected). Also don't wrap the default values in `$(i,...)` anymore because the defaults can trigger line breaks and then the man page is ill-formatted because that format is stupid. Reviewed By: mityal Differential Revision: D16543779 fbshipit-source-id: bc929ff8c
5 years ago
Specify the root directory of the project
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--quiet,-q
Activates: Do not print specs on standard output (default: only
print for the report command) (Conversely: --no-quiet | -Q)
[kill -a][4/4] kill `Config.analyzer`, deprecate `--analyzer` Summary: Keep `--analyzer` around for now for integrations that depend on it. Also deprecate the `--infer-blacklist-path-regex`, `--checkers-blacklist-path-regex`, etc. in favour of `--report-blacklist-path-regex` which more accurately represents what these do as of now. Rely on the current subcommand instead of the analyzer where needed, as most of the code already does. Reviewed By: jeremydubreil Differential Revision: D9942809 fbshipit-source-id: 9380e6036
6 years ago
--report-blacklist-files-containing +string
[config] saner names and doc for blacklist options Summary: Describe what the --report-*-* options actually do instead of their outdated documentation from the time where this was `--checkers-blacklist-regex`, `--infer-blacklist-regex` and the like. Reviewed By: dulmarod, mityal Differential Revision: D17906015 fbshipit-source-id: 204349e9e
5 years ago
Do not report any issues on files containing the specified string
[kill -a][4/4] kill `Config.analyzer`, deprecate `--analyzer` Summary: Keep `--analyzer` around for now for integrations that depend on it. Also deprecate the `--infer-blacklist-path-regex`, `--checkers-blacklist-path-regex`, etc. in favour of `--report-blacklist-path-regex` which more accurately represents what these do as of now. Rely on the current subcommand instead of the analyzer where needed, as most of the code already does. Reviewed By: jeremydubreil Differential Revision: D9942809 fbshipit-source-id: 9380e6036
6 years ago
--report-blacklist-path-regex +path_regex
[config] saner names and doc for blacklist options Summary: Describe what the --report-*-* options actually do instead of their outdated documentation from the time where this was `--checkers-blacklist-regex`, `--infer-blacklist-regex` and the like. Reviewed By: dulmarod, mityal Differential Revision: D17906015 fbshipit-source-id: 204349e9e
5 years ago
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
[kill -a][4/4] kill `Config.analyzer`, deprecate `--analyzer` Summary: Keep `--analyzer` around for now for integrations that depend on it. Also deprecate the `--infer-blacklist-path-regex`, `--checkers-blacklist-path-regex`, etc. in favour of `--report-blacklist-path-regex` which more accurately represents what these do as of now. Rely on the current subcommand instead of the analyzer where needed, as most of the code already does. Reviewed By: jeremydubreil Differential Revision: D9942809 fbshipit-source-id: 9380e6036
6 years ago
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--report-formatter { none | phabricator }
[help] scrub default values in the checked-in version of the manuals Summary: The default values of config options can sometimes depend on build-time configuration values. This makes checking that the manuals "remain the same" trickier as the manuals can be different depending on the platform. This removes *all* default values from the checked-in manuals. We could be more fine-grained and scrub only the values that are susceptible to change but for now this is probably good enough. This is done by implementing new options `--help-scrubbed` and `--help-scrubbed-full` and using these in our tests instead of `--help` and `--help-full` (which remain unaffected). Also don't wrap the default values in `$(i,...)` anymore because the defaults can trigger line breaks and then the man page is ill-formatted because that format is stupid. Reviewed By: mityal Differential Revision: D16543779 fbshipit-source-id: bc929ff8c
5 years ago
Which formatter to use when emitting the report
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
[kill -a][4/4] kill `Config.analyzer`, deprecate `--analyzer` Summary: Keep `--analyzer` around for now for integrations that depend on it. Also deprecate the `--infer-blacklist-path-regex`, `--checkers-blacklist-path-regex`, etc. in favour of `--report-blacklist-path-regex` which more accurately represents what these do as of now. Rely on the current subcommand instead of the analyzer where needed, as most of the code already does. Reviewed By: jeremydubreil Differential Revision: D9942809 fbshipit-source-id: 9380e6036
6 years ago
--report-suppress-errors +error_name
do not report a type of errors
[config] saner names and doc for blacklist options Summary: Describe what the --report-*-* options actually do instead of their outdated documentation from the time where this was `--checkers-blacklist-regex`, `--infer-blacklist-regex` and the like. Reviewed By: dulmarod, mityal Differential Revision: D17906015 fbshipit-source-id: 204349e9e
5 years ago
--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)
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
--results-dir,-o dir
Write results and internal files in the specified directory
--skip-analysis-in-path-skips-compilation
Activates: Whether paths in --skip-analysis-in-path should be
compiled or not (Conversely:
--no-skip-analysis-in-path-skips-compilation)
[hoisting] Hoist only expensive pure functions Reviewed By: mbouaziz Differential Revision: D10236706 fbshipit-source-id: c51a9ff0c
6 years ago
HOISTING OPTIONS
[hoisting] Turn on hoisting of expensive functions by default Reviewed By: mbouaziz Differential Revision: D14971084 fbshipit-source-id: ccbf6055e
6 years ago
--no-hoisting-report-only-expensive
Deactivates: [Hoisting] Report loop-invariant calls only when the
[hoisting] Hoist only expensive pure functions Reviewed By: mbouaziz Differential Revision: D10236706 fbshipit-source-id: c51a9ff0c
6 years ago
function is expensive, i.e. at least linear (Conversely:
[hoisting] Turn on hoisting of expensive functions by default Reviewed By: mbouaziz Differential Revision: D14971084 fbshipit-source-id: ccbf6055e
6 years ago
--hoisting-report-only-expensive)
[man] check in manual pages Summary: This allows infer devs to see the effects their changes have on the infer manuals. Check in the manuals for each subcommand + the output of `--help-full` to get a complete picture. If this is too annoying we can also check in only `--help-full`. Reviewed By: mbouaziz Differential Revision: D9916404 fbshipit-source-id: b981e2c33
6 years ago
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-reportdiff(1), infer-run(1)