Summary:
The internal links for the "old latest" 1.0.0 version were wrong. The
fix to `make new-website-version` is in the next diff.
Reviewed By: martintrojer
Differential Revision: D27360089
fbshipit-source-id: 8abefbd8f
master
Jules Villard4 years agocommitted byFacebook GitHub Bot
Reported as "Autoreleasepool Size Complexity Increase Ui Thread" by [cost](/docs/checker-cost).
Reported as "Autoreleasepool Size Complexity Increase Ui Thread" by [cost](/docs/1.0.0/checker-cost).
\[EXPERIMENTAL\] Infer reports this issue when the ObjC autoreleasepool's complexity of the
procedure increases in degree **and** the procedure runs on the UI (main) thread.
@ -38,14 +38,14 @@ Infer considers a method as running on the UI thread whenever:
## AUTORELEASEPOOL_SIZE_UNREACHABLE_AT_EXIT
Reported as "Autoreleasepool Size Unreachable At Exit" by [cost](/docs/checker-cost).
Reported as "Autoreleasepool Size Unreachable At Exit" by [cost](/docs/1.0.0/checker-cost).
\[EXPERIMENTAL\] This issue type indicates that the program's execution doesn't reach the exit
node. Hence, we cannot compute a static bound of ObjC autoreleasepool's size for the procedure.
## BAD_POINTER_COMPARISON
Reported as "Bad Pointer Comparison" by [linters](/docs/checker-linters).
Reported as "Bad Pointer Comparison" by [linters](/docs/1.0.0/checker-linters).
Infer reports these warnings in Objective-C when a boxed primitive type such as
`NSNumber *` is coerced to a boolean in a comparison. For example, consider the
@ -64,12 +64,12 @@ compare `n` to `nil` or call an accessor to clarify her intention.
## BIABDUCTION_MEMORY_LEAK
Reported as "Memory Leak" by [biabduction](/docs/checker-biabduction).
Reported as "Memory Leak" by [biabduction](/docs/1.0.0/checker-biabduction).
See [MEMORY_LEAK](#memory_leak).
## BUFFER_OVERRUN_L1
Reported as "Buffer Overrun L1" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Buffer Overrun L1" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
Buffer overrun reports fall into several "buckets" corresponding to the expected precision of the
report. The higher the number, the more likely it is to be a false positive.
@ -97,37 +97,37 @@ report. The higher the number, the more likely it is to be a false positive.
## BUFFER_OVERRUN_L2
Reported as "Buffer Overrun L2" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Buffer Overrun L2" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
See [BUFFER_OVERRUN_L1](#buffer_overrun_l1)
## BUFFER_OVERRUN_L3
Reported as "Buffer Overrun L3" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Buffer Overrun L3" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
See [BUFFER_OVERRUN_L1](#buffer_overrun_l1)
## BUFFER_OVERRUN_L4
Reported as "Buffer Overrun L4" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Buffer Overrun L4" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
See [BUFFER_OVERRUN_L1](#buffer_overrun_l1)
## BUFFER_OVERRUN_L5
Reported as "Buffer Overrun L5" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Buffer Overrun L5" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
See [BUFFER_OVERRUN_L1](#buffer_overrun_l1)
## BUFFER_OVERRUN_S2
Reported as "Buffer Overrun S2" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Buffer Overrun S2" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
See [BUFFER_OVERRUN_L1](#buffer_overrun_l1)
## BUFFER_OVERRUN_U5
Reported as "Buffer Overrun U5" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Buffer Overrun U5" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
See [BUFFER_OVERRUN_L1](#buffer_overrun_l1)
## CAPTURED_STRONG_SELF
Reported as "Captured strongSelf" by [self-in-block](/docs/checker-self-in-block).
Reported as "Captured strongSelf" by [self-in-block](/docs/1.0.0/checker-self-in-block).
This will happen in one of two cases generally:
@ -140,7 +140,7 @@ This will happen in one of two cases generally:
## CHECKERS_ALLOCATES_MEMORY
Reported as "Allocates Memory" by [annotation-reachability](/docs/checker-annotation-reachability).
Reported as "Allocates Memory" by [annotation-reachability](/docs/1.0.0/checker-annotation-reachability).
A method annotated with `@NoAllocation` transitively calls `new`.
@ -157,13 +157,13 @@ class C implements I {
## CHECKERS_ANNOTATION_REACHABILITY_ERROR
Reported as "Annotation Reachability Error" by [annotation-reachability](/docs/checker-annotation-reachability).
Reported as "Annotation Reachability Error" by [annotation-reachability](/docs/1.0.0/checker-annotation-reachability).
A method annotated with an annotation `@A` transitively calls a method annotated `@B` where the combination of annotations is forbidden (for example, `@UiThread` calling `@WorkerThread`).
## CHECKERS_CALLS_EXPENSIVE_METHOD
Reported as "Expensive Method Called" by [annotation-reachability](/docs/checker-annotation-reachability).
Reported as "Expensive Method Called" by [annotation-reachability](/docs/1.0.0/checker-annotation-reachability).
A method annotated with `@PerformanceCritical` transitively calls a method annotated `@Expensive`.
@ -183,7 +183,7 @@ class C {
## CHECKERS_EXPENSIVE_OVERRIDES_UNANNOTATED
Reported as "Expensive Overrides Unannotated" by [annotation-reachability](/docs/checker-annotation-reachability).
Reported as "Expensive Overrides Unannotated" by [annotation-reachability](/docs/1.0.0/checker-annotation-reachability).
A method annotated with `@Expensive` overrides an un-annotated method.
@ -202,7 +202,7 @@ class A implements I {
## CHECKERS_FRAGMENT_RETAINS_VIEW
Reported as "Fragment Retains View" by [fragment-retains-view](/docs/checker-fragment-retains-view).
Reported as "Fragment Retains View" by [fragment-retains-view](/docs/1.0.0/checker-fragment-retains-view).
This error type is Android-specific. It fires when a `Fragment` type fails to
nullify one or more of its declared `View` fields in `onDestroyView`. In
@ -216,7 +216,7 @@ Action: Nullify the `View` in question in `onDestroyView`.
## CHECKERS_IMMUTABLE_CAST
Reported as "Checkers Immutable Cast" by [immutable-cast](/docs/checker-immutable-cast).
Reported as "Checkers Immutable Cast" by [immutable-cast](/docs/1.0.0/checker-immutable-cast).
This error type is reported in Java. It fires when an immutable collection is
returned from a method whose type is mutable.
@ -236,7 +236,7 @@ collection so that it can be modified.
## CHECKERS_PRINTF_ARGS
Reported as "Checkers Printf Args" by [printf-args](/docs/checker-printf-args).
Reported as "Checkers Printf Args" by [printf-args](/docs/1.0.0/checker-printf-args).
This error is reported when the argument types to a `printf` method do not match the format string.
@ -250,27 +250,27 @@ Action: fix the mismatch between format string and argument types.
## COMPONENT_WITH_MULTIPLE_FACTORY_METHODS
Reported as "Component With Multiple Factory Methods" by [linters](/docs/checker-linters).
Reported as "Component With Multiple Factory Methods" by [linters](/docs/1.0.0/checker-linters).
## CONDITION_ALWAYS_FALSE
Reported as "Condition Always False" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Condition Always False" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
A condition expression is **always** evaluated to false.
## CONDITION_ALWAYS_TRUE
Reported as "Condition Always True" by [bufferoverrun](/docs/checker-bufferoverrun).
Reported as "Condition Always True" by [bufferoverrun](/docs/1.0.0/checker-bufferoverrun).
A condition expression is **always** evaluated to true.
## CONFIG_CHECKS_BETWEEN_MARKERS
Reported as "Config Checks Between Markers" by [config-checks-between-markers](/docs/checker-config-checks-between-markers).
Reported as "Config Checks Between Markers" by [config-checks-between-markers](/docs/1.0.0/checker-config-checks-between-markers).
A config checking is done between a marker's start and end
## CONSTANT_ADDRESS_DEREFERENCE
Reported as "Constant Address Dereference" by [pulse](/docs/checker-pulse).
Reported as "Constant Address Dereference" by [pulse](/docs/1.0.0/checker-pulse).
This is reported when an address obtained via a non-zero constant is
dereferenced. If the address is zero then
@ -281,17 +281,17 @@ type.
## CREATE_INTENT_FROM_URI
Reported as "Create Intent From Uri" by [quandary](/docs/checker-quandary).
Reported as "Create Intent From Uri" by [quandary](/docs/1.0.0/checker-quandary).
Create an intent/start a component using a (possibly user-controlled) URI. may or may not be an issue depending on where the URI comes from.
## CROSS_SITE_SCRIPTING
Reported as "Cross Site Scripting" by [quandary](/docs/checker-quandary).
Reported as "Cross Site Scripting" by [quandary](/docs/1.0.0/checker-quandary).
Untrusted data flows into HTML; XSS risk.
## CXX_REFERENCE_CAPTURED_IN_OBJC_BLOCK
Reported as "Cxx Reference Captured In Objc Block" by [linters](/docs/checker-linters).
Reported as "Cxx Reference Captured In Objc Block" by [linters](/docs/1.0.0/checker-linters).
With this check, Infer detects C++ references captured in a block. Doing this is
almost always wrong. The reason is that C++ references are not managed pointers
@ -310,12 +310,12 @@ const int copied_v = v;
## DANGLING_POINTER_DEREFERENCE
Reported as "Dangling Pointer Dereference" by [biabduction](/docs/checker-biabduction).
Reported as "Dangling Pointer Dereference" by [biabduction](/docs/1.0.0/checker-biabduction).
## DEADLOCK
Reported as "Deadlock" by [starvation](/docs/checker-starvation).
Reported as "Deadlock" by [starvation](/docs/1.0.0/checker-starvation).
This error is currently reported in Java. A deadlock occurs when two distinct
threads try to acquire two locks in reverse orders. The following code
@ -380,14 +380,14 @@ To suppress reports of deadlocks in a method `m()` use the
## DEAD_STORE
Reported as "Dead Store" by [liveness](/docs/checker-liveness).
Reported as "Dead Store" by [liveness](/docs/1.0.0/checker-liveness).
This error is reported in C++. It fires when the value assigned to a variables
is never used (e.g., `int i = 1; i = 2; return i;`).
## DIRECT_ATOMIC_PROPERTY_ACCESS
Reported as "Direct Atomic Property Access" by [linters](/docs/checker-linters).
Reported as "Direct Atomic Property Access" by [linters](/docs/1.0.0/checker-linters).
This check warns you when you are accessing an atomic property directly with an
ivar. This makes the atomic property not atomic anymore. So potentially you may
@ -397,7 +397,7 @@ To fix the problem you need to access properties with their getter or setter.
## DISCOURAGED_WEAK_PROPERTY_CUSTOM_SETTER
Reported as "Discouraged Weak Property Custom Setter" by [linters](/docs/checker-linters).
Reported as "Discouraged Weak Property Custom Setter" by [linters](/docs/1.0.0/checker-linters).
This check warns you when you have a custom setter for a weak property. When
compiled with Automatic Reference Counting (ARC, `-fobj-arc`) ARC may set the
@ -466,12 +466,12 @@ Note that the custom setter was only invoked once.
## DIVIDE_BY_ZERO
Reported as "Divide By Zero" by [biabduction](/docs/checker-biabduction).
Reported as "Divide By Zero" by [biabduction](/docs/1.0.0/checker-biabduction).
## EMPTY_VECTOR_ACCESS
Reported as "Empty Vector Access" by [biabduction](/docs/checker-biabduction).
Reported as "Empty Vector Access" by [biabduction](/docs/1.0.0/checker-biabduction).
This error type is reported only in C++, in versions >= C++11.
@ -488,12 +488,12 @@ int foo(){
## ERADICATE_BAD_NESTED_CLASS_ANNOTATION
Reported as "@Nullsafe annotation is inconsistent with outer class" by [eradicate](/docs/checker-eradicate).
Reported as "@Nullsafe annotation is inconsistent with outer class" by [eradicate](/docs/1.0.0/checker-eradicate).
## ERADICATE_CONDITION_REDUNDANT
Reported as "Condition Redundant" by [eradicate](/docs/checker-eradicate).
Reported as "Condition Redundant" by [eradicate](/docs/1.0.0/checker-eradicate).
This report is inactive by default. Condition (x != null) or (x == null) when x
cannot be null: the first condition is always true and the second is always
@ -520,7 +520,7 @@ relevant. If the annotations are correct, you can remove the redundant case.
## ERADICATE_FIELD_NOT_INITIALIZED
Reported as "Field Not Initialized" by [eradicate](/docs/checker-eradicate).
Reported as "Field Not Initialized" by [eradicate](/docs/1.0.0/checker-eradicate).
The constructor does not initialize a field f which is not annotated with
@Nullable
@ -542,7 +542,7 @@ annotated with @Nullable.
## ERADICATE_FIELD_NOT_NULLABLE
Reported as "Field Not Nullable" by [eradicate](/docs/checker-eradicate).
Reported as "Field Not Nullable" by [eradicate](/docs/1.0.0/checker-eradicate).
An assignment x.f = v where v could be null and field f is not annotated with
@Nullable.
@ -567,12 +567,12 @@ values.
## ERADICATE_FIELD_OVER_ANNOTATED
Reported as "Field Over Annotated" by [eradicate](/docs/checker-eradicate).
Reported as "Field Over Annotated" by [eradicate](/docs/1.0.0/checker-eradicate).
Reported as "Expensive Loop Invariant Call" by [loop-hoisting](/docs/checker-loop-hoisting).
Reported as "Expensive Loop Invariant Call" by [loop-hoisting](/docs/1.0.0/checker-loop-hoisting).
We report this issue type when a function is [loop-invariant](/docs/all-issue-types#invariant_call) and also expensive (i.e. at least has linear complexity as determined by the [cost](/docs/checker-cost) analysis).
We report this issue type when a function is [loop-invariant](/docs/1.0.0/all-issue-types#invariant_call) and also expensive (i.e. at least has linear complexity as determined by the [cost](/docs/1.0.0/checker-cost) analysis).
where `foo` has a linear cost in its parameter, then Infer automatically detects that the complexity of loop has increased from `O(|list|)` to `O(|list|^2)` and then reports an [`EXECUTION_TIME_COMPLEXITY_INCREASE`](/docs/all-issue-types#execution_time_complexity_increase) issue.
where `foo` has a linear cost in its parameter, then Infer automatically detects that the complexity of loop has increased from `O(|list|)` to `O(|list|^2)` and then reports an [`EXECUTION_TIME_COMPLEXITY_INCREASE`](/docs/1.0.0/all-issue-types#execution_time_complexity_increase) issue.
@ -90,11 +90,11 @@ There are a number of known limitations to the design of the static cost analysi
## List of Issue Types
The following issue types are reported by this checker:
This is an experimental inter-procedural analysis that detects impure functions. It is meant to be an improvement over the [purity](/docs/checker-purity) analysis with a negation on the issue types. For each function, impurity analysis keeps track of not only the impurity of the function but also some additional information such as which parameters/globals the function modifies. It models functions with no summary/model as impure. The analysis relies on [Pulse](/docs/checker-pulse) summaries to determine impurity.
This is an experimental inter-procedural analysis that detects impure functions. It is meant to be an improvement over the [purity](/docs/1.0.0/checker-purity) analysis with a negation on the issue types. For each function, impurity analysis keeps track of not only the impurity of the function but also some additional information such as which parameters/globals the function modifies. It models functions with no summary/model as impure. The analysis relies on [Pulse](/docs/1.0.0/checker-pulse) summaries to determine impurity.
## List of Issue Types
The following issue types are reported by this checker:
This checker detects opportunities to hoist function calls that are invariant to outside of loop bodies. The hoisting analysis relies on [purity](/docs/checker-purity) analysis to determine whather a function is pure or not.
This checker detects opportunities to hoist function calls that are invariant to outside of loop bodies. The hoisting analysis relies on [purity](/docs/1.0.0/checker-purity) analysis to determine whather a function is pure or not.
It has an additional mode that reports [loop-invariant functions that are expensive](/docs/all-issue-types#expensive_loop_invariant_call) (i.e. at least linear). This is enabled by the flag `--hoisting-report-only-expensive`.
It has an additional mode that reports [loop-invariant functions that are expensive](/docs/1.0.0/all-issue-types#expensive_loop_invariant_call) (i.e. at least linear). This is enabled by the flag `--hoisting-report-only-expensive`.
## List of Issue Types
The following issue types are reported by this checker:
This is an experimental inter-procedural analysis that detects pure (side-effect free) functions. For each function, purity analysis keeps track of not only the purity of the function but also some additional information such as whether the function modifies a global variable or which of the parameters are modified. It models functions with no summary/model as modifying the global state (hence impure).
If the function is pure (i.e. doesn't modify any global state or its parameters and doesn't call any unknown functions), then it reports an [`PURE_FUNCTION`](/docs/all-issue-types#pure_function) issue.
If the function is pure (i.e. doesn't modify any global state or its parameters and doesn't call any unknown functions), then it reports an [`PURE_FUNCTION`](/docs/1.0.0/all-issue-types#pure_function) issue.
## Weaknesses
@ -31,7 +31,7 @@ void foo(Foo a){
}
```
in order to determine that `foo` is impure, we need to know that the write to `b`'s field is actually changing the function parameter `a`, i.e. we need to check if `b` is aliasing `a`. This is known as alias analysis and is hard to get right in a scalable manner. When this analysis was being developed, Infer didn't have a unified alias analysis and using biabduction seemed like a too daunting task at the time. Hence, we relied on [InferBo](/docs/checker-bufferoverrun)'s aliasing mechanism which was easy to invoke and integrate with. However, InferBo's aliasing analysis is far from perfect and causes issues for purity.
in order to determine that `foo` is impure, we need to know that the write to `b`'s field is actually changing the function parameter `a`, i.e. we need to check if `b` is aliasing `a`. This is known as alias analysis and is hard to get right in a scalable manner. When this analysis was being developed, Infer didn't have a unified alias analysis and using biabduction seemed like a too daunting task at the time. Hence, we relied on [InferBo](/docs/1.0.0/checker-bufferoverrun)'s aliasing mechanism which was easy to invoke and integrate with. However, InferBo's aliasing analysis is far from perfect and causes issues for purity.
To see the issue with the second point, consider the following program:
```java
@ -50,16 +50,16 @@ boolean contains(Integer i, ArrayList<Integer> list){
The existing purity analysis concludes that the above function `contains` is impure because it calls an impure function `next()` which modifies the iterator (hence it thinks it also modifies the `list`). However, notice that `contains` doesn't have an observable side-effect: `list.iterator()` returns a new object, `hasNext()` and `equals()` are pure, and `next()` only modifies the fields of the fresh object `listIterator`. Therefore, `contains` should be considered as pure.
To alleviate this problem, we have developed an [Impurity](/docs/checker-impurity) analysis which uses [pulse](/docs/checker-pulse) which can successfully analyze this program as pure \o/
To alleviate this problem, we have developed an [Impurity](/docs/1.0.0/checker-impurity) analysis which uses [pulse](/docs/1.0.0/checker-pulse) which can successfully analyze this program as pure \o/
The analysis is used by:
- [Loop-hoisting](/docs/checker-loop-hoisting) analysis which identifies loop-invariant function calls, i.e. functions that are pure and have loop-invariant arguments.
- [Cost](/docs/checker-cost) analysis which identifies control variables in the loop that affect how many times a loop is executed. In this computation, we need to prune control variables that do not affect how many times a loop is executed. In this pruning step, we need to compute loop-invariant variables (which requires the above analysis).
- [Loop-hoisting](/docs/1.0.0/checker-loop-hoisting) analysis which identifies loop-invariant function calls, i.e. functions that are pure and have loop-invariant arguments.
- [Cost](/docs/1.0.0/checker-cost) analysis which identifies control variables in the loop that affect how many times a loop is executed. In this computation, we need to prune control variables that do not affect how many times a loop is executed. In this pruning step, we need to compute loop-invariant variables (which requires the above analysis).
## List of Issue Types
The following issue types are reported by this checker:
Jules Villard
4 years ago
committed by
Facebook GitHub Bot