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 'e0b688ceab'
${ noResults }
infer_clone/infer/tests/codetoanalyze/java/nullsafe-default/issues.exp

243 lines
84 KiB
Raw Normal View History Unescape

[nullsafe][refactor tests] split and improve FieldNotNullable tests Summary: See motivation below. This diff is dealing with FieldNotNullable: - move not relevant subclasses into dedicated classes and files - modify the tests so they comply with the standards below --Motivation-- Gradual mode we are going to introduce is an invasive change in how Infer treats nullability semantics. In order to make the change in a controllable way, we need the tests to comply with the following standards and conventions. 1. For each code peace where we expect a bug to happen, the there should be corresponding (minimally different from above) peace of code where we expect a bug to NOT happen. (This is to ensure bug is happening for exact reason we think it is happening). 2. Conversely: for each peace of code where we expect a bug to be NOT present, there shuold be a peace of code where the bug IS happening. (Otherwise there can be too many reasons for a bug NOT to happen). 3. Convention: end corresponding methods IsOK and IsBUG correspondingly. 4. Keep code examples as small as possible. Reviewed By: ngorogiannis Differential Revision: D17183222 fbshipit-source-id: 83d03e67f
5 years ago
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife$TestNotInitialized.<init>(codetoanalyze.java.nullsafe_default.ButterKnife), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `ButterKnife$TestNotInitialized.notInitializedNormalIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
[nullsafe] Add a test for field-overannotated warning Summary: Turns out, we did not have such a test in place. Known issue: we report over-annotated warnings for each fields N times, one per constructor, which is wrong. Reviewed By: artempyanykh Differential Revision: D17574791 fbshipit-source-id: def992691
5 years ago
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife.<init>(), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `ButterKnife.nullable` is always initialized in the constructor but is declared `@Nullable`]
[nullsafe][refactor tests] split and improve FieldNotNullable tests Summary: See motivation below. This diff is dealing with FieldNotNullable: - move not relevant subclasses into dedicated classes and files - modify the tests so they comply with the standards below --Motivation-- Gradual mode we are going to introduce is an invasive change in how Infer treats nullability semantics. In order to make the change in a controllable way, we need the tests to comply with the following standards and conventions. 1. For each code peace where we expect a bug to happen, the there should be corresponding (minimally different from above) peace of code where we expect a bug to NOT happen. (This is to ensure bug is happening for exact reason we think it is happening). 2. Conversely: for each peace of code where we expect a bug to be NOT present, there shuold be a peace of code where the bug IS happening. (Otherwise there can be too many reasons for a bug NOT to happen). 3. Convention: end corresponding methods IsOK and IsBUG correspondingly. 4. Keep code examples as small as possible. Reviewed By: ngorogiannis Differential Revision: D17183222 fbshipit-source-id: 83d03e67f
5 years ago
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife.assignNullToNormalIsBAD():void, 1, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `ButterKnife.normal` can be null but is not declared `@Nullable`. (Origin: null constant at line 76)]
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife.convertingToNotNullableForNullableIsBAD():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `convertingToNotNullableForNullableIsBAD()` may return null but it is not annotated with `@Nullable`. (Origin: field ButterKnife.nullable at line 47)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife.dereferencingNullableIsBAD():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ButterKnife.nullable` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife.passingToNullableForNullableIsBAD():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ButterKnife.f(...)` needs a non-null value in parameter 1 but argument `ButterKnife.nullable` can be null.]
codetoanalyze/java/nullsafe-default/CapturedParam.java, codetoanalyze.java.nullsafe_default.CapturedParam.dereferencingNullableIsBAD(java.lang.Object):void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`parameter` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Add a test for field-overannotated warning Summary: Turns out, we did not have such a test in place. Known issue: we report over-annotated warnings for each fields N times, one per constructor, which is wrong. Reviewed By: artempyanykh Differential Revision: D17574791 fbshipit-source-id: def992691
5 years ago
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.<init>(), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `ConditionRedundant.fieldNullable` is always initialized in the constructor but is declared `@Nullable`]
[nullsafe] More test cases for Condition Redundant Summary: This will simplify modifying functionality around this type of error. Also rename the file for clarity. Reviewed By: jvillard Differential Revision: D17397144 fbshipit-source-id: 552215243
5 years ago
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.FP_ternary_NonnullInOneBranch_SecondBranch_ShouldBeOK(java.lang.String,java.lang.String,int):void, 2, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s2 is always false according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.assertNotNull_NonnullIsBAD(java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition (s!=null) is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.checkArgument_NonnullIsBAd(java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.checkNotNull_NonnullIsBAD(java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition (s!=null) is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.compareEQ_NonnullIsBAD(java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s is always false according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.compareNEQ_NonnullIsBAD(java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.comparingNonnullFieldIsBAD():void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition ConditionRedundant.fieldNonnull is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.comparingNonnullFunctionIsBAD():void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition lang.String(this)V is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.comparingNullableFieldThatIsAlreadyCheckedIsBAD():void, 2, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition ConditionRedundant.fieldNullable is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.comparingWithNullIfAssignedBeforeThrowableIsBAD():void, 6, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.conjunctionBothNonnullIsBAD(java.lang.String,java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s1 is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.conjunctionBothNonnullIsBAD(java.lang.String,java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s2 is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.conjunctionOneNonnullIsBAD(java.lang.String,java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s2 is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.disjunctionBothNonnullIsBAD(java.lang.String,java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s2 is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.disjunctionBothNonnullIsBAD(java.lang.String,java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s1 is always false according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.disjunctionOneNonnullIsBAD(java.lang.String,java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s2 is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.irrelevantConditionWithNonnullIsBAD(java.lang.String,java.lang.String,int):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s1 is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.outsideOfIfCompareNonnullIsBAD(java.lang.String):void, 1, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.ternary_NonnullInBothBranchesIsBAD(java.lang.String,java.lang.String,int):void, 2, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s2 is always false according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.testFlowSensitivity(java.lang.String,java.lang.String):void, 2, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition nullable1 is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/ConditionRedundant.java, codetoanalyze.java.nullsafe_default.ConditionRedundant.testFlowSensitivity(java.lang.String,java.lang.String):void, 4, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition nullable1 is always true according to the existing annotations.]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$Test.testEarlyReturn(java.lang.CharSequence,java.lang.CharSequence):void, 6, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s2` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$Test.testFalseOnNull(java.lang.CharSequence):void, 8, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$Test.testFalseOnNull(java.lang.CharSequence):void, 12, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Make test for @TrueOnNull and @FalseOnNull annotation specific about positive and negative cases Summary: Let's consolidate "positive" and "negative" cased together by adding an example of not annotated class as a source of "negative" cases. Also join the case with modelled methods to the same class. Reviewed By: jberdine Differential Revision: D17284101 fbshipit-source-id: e15e60691
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$Test.testModelledTrueOnNull(java.lang.String):void, 2, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s is always false according to the existing annotations.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$Test.testModelledTrueOnNull(java.lang.String):void, 7, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition s is always false according to the existing annotations.]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$Test.testTrueOnNull(java.lang.CharSequence):void, 8, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$Test.testTrueOnNull(java.lang.CharSequence):void, 12, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Introduce DeclaredNonnull Summary: This is an intermediate nullability type powering future Strict mode. See the next diff. Reviewed By: artempyanykh Differential Revision: D17977909 fbshipit-source-id: 2d5ab66d4
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestBothParams.testBothParamsShouldBeNonnull(java.lang.String,java.lang.String):void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: method parameter sNullable)]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestBothParams.testBothParamsShouldBeNonnull(java.lang.String,java.lang.String):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: method parameter sNullable)]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestBothParams.testBothParamsShouldBeNonnull(java.lang.String,java.lang.String):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: method parameter sNullable)]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: null constant at line 120)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
[nullsafe] Introduce DeclaredNonnull Summary: This is an intermediate nullability type powering future Strict mode. See the next diff. Reviewed By: artempyanykh Differential Revision: D17977909 fbshipit-source-id: 2d5ab66d4
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 6, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: method parameter sNullable)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 7, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 11, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 15, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
[nullsafe] Introduce DeclaredNonnull Summary: This is an intermediate nullability type powering future Strict mode. See the next diff. Reviewed By: artempyanykh Differential Revision: D17977909 fbshipit-source-id: 2d5ab66d4
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 21, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: method parameter sNullable)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestOneParameter.test(java.lang.String,java.lang.String):void, 22, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
[nullsafe] Introduce DeclaredNonnull Summary: This is an intermediate nullability type powering future Strict mode. See the next diff. Reviewed By: artempyanykh Differential Revision: D17977909 fbshipit-source-id: 2d5ab66d4
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestReturnValueAnnotationIsAutomaticallyInferred.annotated_dereferencingAfterPassingNullableIsBAD(java.lang.String):void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`annotatedReturn(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: method parameter s)]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestReturnValueAnnotationIsAutomaticallyInferred.notAnnotated_dereferencingAfterPassingNullableIsBAD(java.lang.String):void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`notAnnotatedReturn(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: method parameter s)]
[nullsafe] When inferring type based on the formal type, respect NullsafeType instead of reading annotations Summary: This continues work for eliminating Annot.Item.t from Nullsafe low-level code. The introduced function `from_nullsafe_type` is called when we infer initial type of the equation based on the function or field formal signature. Before that, we did it via reading the annotation directly, which complicates the logic and making introducing Unknown nullability tricky. ## Clarifying the semantics of PropagatesNullable This diff also clarifies (and changes) the behavior of PropagatesNullable params. Previously, if the return value of a function that has PropagatesNullable params was annotated as Nullable, nullsafe was effectively ignoring PropagatesNullable effect. This is especially bad because one can add Nullable annotation based on the logic "if the function can return `null`, it should be annotated with Nullable`. In the new design, there is no possibility for such a misuse: the code that applies the rule "any param is PropagatesNullable hence the return value is nullable even if not explicitly annotated" lives in NullsafeType.ml, so this will be automatically taken into account. Meaning that now we implicitly deduce Nullable annotation for the return value, and providing it explicitly as an alternative that does not change the effect. In the future, we might consider annotating the return value with `Nullable` explicit. Reviewed By: jvillard Differential Revision: D17479157 fbshipit-source-id: 66c2c8777
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestReturnValueAnnotationIsAutomaticallyInferred.notAnnotatingReturnWhenThereAreNoPropagatesNullableIsBAD(java.lang.String):java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `notAnnotatingReturnWhenThereAreNoPropagatesNullableIsBAD(...)` may return null but it is not annotated with `@Nullable`. (Origin: null constant at line 213)]
[nullsafe] Introduce DeclaredNonnull Summary: This is an intermediate nullability type powering future Strict mode. See the next diff. Reviewed By: artempyanykh Differential Revision: D17977909 fbshipit-source-id: 2d5ab66d4
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestSecondParameter.test(java.lang.String,java.lang.String):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: method parameter sNullable)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestSecondParameter.test(java.lang.String,java.lang.String):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
[nullsafe] Introduce DeclaredNonnull Summary: This is an intermediate nullability type powering future Strict mode. See the next diff. Reviewed By: artempyanykh Differential Revision: D17977909 fbshipit-source-id: 2d5ab66d4
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestSecondParameter.test(java.lang.String,java.lang.String):void, 6, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`propagatesNullable(...)` is nullable and is not locally checked for null when calling `length()`. (Origin: method parameter sNullable)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestSecondParameter.test(java.lang.String,java.lang.String):void, 7, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestSecondParameter.test(java.lang.String,java.lang.String):void, 11, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/CustomAnnotations.java, codetoanalyze.java.nullsafe_default.CustomAnnotations$TestPropagatesNullable$TestSecondParameter.test(java.lang.String,java.lang.String):void, 15, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullable(...)` is nullable and is not locally checked for null when calling `length()`.]
[nullsafe] Make FieldNotInitialized cover negative cases together with positive ones Summary: let's always have positive and negative case for each feature we test Reviewed By: ngorogiannis Differential Revision: D17206785 fbshipit-source-id: 5791ace48
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitCircular.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$InitCircular.bad` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitCircular.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$InitCircular.stillBad` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitIfNull.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$InitIfNull.shouldBeGood_FIXME` is not initialized in the constructor and is not declared `@Nullable`]
[nullsafe] Add a test for field-overannotated warning Summary: Turns out, we did not have such a test in place. Known issue: we report over-annotated warnings for each fields N times, one per constructor, which is wrong. Reviewed By: artempyanykh Differential Revision: D17574791 fbshipit-source-id: def992691
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitWithOtherClass$OtherClass.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitWithOtherClass), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldNotInitialized$InitWithOtherClass$OtherClass.nullable` is always initialized in the constructor but is declared `@Nullable`]
[nullafe] Consolidate different ways to suppress field not initialized Summary: See title Reviewed By: artempyanykh Differential Revision: D17281701 fbshipit-source-id: 5a2775f3e
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitWithOtherClass.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized,codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitWithOtherClass$OtherClass), 1, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotInitialized$InitWithOtherClass.bad` can be null but is not declared `@Nullable`. (Origin: field FieldNotInitialized$InitWithOtherClass$OtherClass.nullable at line 182)]
[nullsafe] Make FieldNotInitialized cover negative cases together with positive ones Summary: let's always have positive and negative case for each feature we test Reviewed By: ngorogiannis Differential Revision: D17206785 fbshipit-source-id: 5791ace48
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitWithTheSameClass.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized,codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitWithTheSameClass), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$InitWithTheSameClass.bad` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$InitializationOrder.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized,int), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$InitializationOrder.o1` is not initialized in the constructor and is not declared `@Nullable`]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$OnlyRead.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$OnlyRead.o` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$OnlyReadIndirect.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$OnlyReadIndirect.o1` is not initialized in the constructor and is not declared `@Nullable`]
[nullsafe] Make FieldNotInitialized cover negative cases together with positive ones Summary: let's always have positive and negative case for each feature we test Reviewed By: ngorogiannis Differential Revision: D17206785 fbshipit-source-id: 5791ace48
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$ShouldInitializeInAllBranches.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized,int), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$ShouldInitializeInAllBranches.f3` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$ShouldInitializeInAllBranches.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized,int), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$ShouldInitializeInAllBranches.f5` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$ShouldInitializeInAllBranches.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized,int), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$ShouldInitializeInAllBranches.f2` is not initialized in the constructor and is not declared `@Nullable`]
[nullafe] Consolidate different ways to suppress field not initialized Summary: See title Reviewed By: artempyanykh Differential Revision: D17281701 fbshipit-source-id: 5a2775f3e
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.nonnullIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.notNullIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.suppressWrongLintIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.nonNullIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.testNullifyFields():void, 3, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.nonnullIsBAD` can be null but is not declared `@Nullable`. (Origin: null constant at line 59)]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.testNullifyFields():void, 4, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.nonNullIsBAD` can be null but is not declared `@Nullable`. (Origin: null constant at line 60)]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.testNullifyFields():void, 5, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.injectIsOK` can be null but is not declared `@Nullable`. (Origin: null constant at line 61)]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.testNullifyFields():void, 6, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.suppressAnnotationIsOK` can be null but is not declared `@Nullable`. (Origin: null constant at line 62)]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.testNullifyFields():void, 7, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotInitialized$Suppression.suppressLintIsOK` can be null but is not declared `@Nullable`. (Origin: null constant at line 63)]
[nullsafe] Make FieldNotInitialized cover negative cases together with positive ones Summary: let's always have positive and negative case for each feature we test Reviewed By: ngorogiannis Differential Revision: D17206785 fbshipit-source-id: 5791ace48
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$WriteItselfIsBAD.<init>(codetoanalyze.java.nullsafe_default.FieldNotInitialized), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `FieldNotInitialized$WriteItselfIsBAD.bad` is not initialized in the constructor and is not declared `@Nullable`]
[nullsafe] Make @Initializer annotation test specific and without "builder" boilerplate Summary: 1. Remove boilerplate with builder that uses builder initializer; it demostates a usecase but it is not really relevant for the test so it distracts attention. Instead, describe the usecase in the comment 2. Add good and bad cases so it is obvious what exactly do we test. Reviewed By: artempyanykh Differential Revision: D17204969 fbshipit-source-id: 005ea078b
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.<init>(), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `TestInitializerAnnotation.dontInitAtAllIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.<init>(), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `TestInitializerAnnotation.initInAnyOtherMethodIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.build():java.lang.Object, 5, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition TestInitializerAnnotation.initInInitilizerMethod2IsOK is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.build():java.lang.Object, 5, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition TestInitializerAnnotation.initInInitilizerMethod1IsOK is always true according to the existing annotations.]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.set4(java.lang.String):void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `TestInitializerAnnotation.initByNullableInInitializedMethodIsBAD` can be null but is not declared `@Nullable`. (Origin: method parameter value)]
[nullsafe] Consolidate and expand tests for known initializers Summary: 1. Let's move it to the file dedicated to this particular warning. 2. Make it more general (Activity was just a particular case) and describe in comments what it really does. Reviewed By: ngorogiannis Differential Revision: D17205919 fbshipit-source-id: 82bf5e9bd
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestKnownInitializers$KnownInitializers.<init>(codetoanalyze.java.nullsafe_default.TestKnownInitializers), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `TestKnownInitializers$KnownInitializers.initInUnknownMethodIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestKnownInitializers$SimplyOnCreateWontDoATrick.<init>(codetoanalyze.java.nullsafe_default.TestKnownInitializers), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `TestKnownInitializers$SimplyOnCreateWontDoATrick.initInUnknownMethodIsBAD` is not initialized in the constructor and is not declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.CanAssignNullInCleanupMethods.assignNullInAnyOtherMethodIsBAD():void, 1, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `CanAssignNullInCleanupMethods.someObject` can be null but is not declared `@Nullable`. (Origin: null constant at line 44)]
[nullsafe] Add a test for field-overannotated warning Summary: Turns out, we did not have such a test in place. Known issue: we report over-annotated warnings for each fields N times, one per constructor, which is wrong. Reviewed By: artempyanykh Differential Revision: D17574791 fbshipit-source-id: def992691
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.<init>(), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldNotNullable.nullable` is always initialized in the constructor but is declared `@Nullable`]
[nullsafe] Consolidate and expand tests for known initializers Summary: 1. Let's move it to the file dedicated to this particular warning. 2. Make it more general (Activity was just a particular case) and describe in comments what it really does. Reviewed By: ngorogiannis Differential Revision: D17205919 fbshipit-source-id: 82bf5e9bd
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.<init>(), 4, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotNullable.initializeNonNullableWithNullIsBAD` can be null but is not declared `@Nullable`. (Origin: null constant at line 52)]
[nullsafe] Make FieldNotNullable test specific about both positive and negative cases Summary: 1. Remove manipulations with "shadowed" fields and abstract class, I don't believe they produced high quality signal (and no related warnings in the test output). 2. For each failure case provide corresponding success case and the reverse Reviewed By: artempyanykh Differential Revision: D17203240 fbshipit-source-id: c809857ed
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.getNullable():java.lang.String, 0, ERADICATE_RETURN_OVER_ANNOTATED, no_bucket, WARNING, [Method `getNullable()` is annotated with `@Nullable` but never returns null.]
[nullsafe] Consolidate and expand tests for known initializers Summary: 1. Let's move it to the file dedicated to this particular warning. 2. Make it more general (Activity was just a particular case) and describe in comments what it really does. Reviewed By: ngorogiannis Differential Revision: D17205919 fbshipit-source-id: 82bf5e9bd
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.setNullableToNotNullableIsBAD(java.lang.String):void, 1, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotNullable.notNullable` can be null but is not declared `@Nullable`. (Origin: null constant at line 65)]
[nullsafe] Make FieldNotNullable test specific about both positive and negative cases Summary: 1. Remove manipulations with "shadowed" fields and abstract class, I don't believe they produced high quality signal (and no related warnings in the test output). 2. For each failure case provide corresponding success case and the reverse Reviewed By: artempyanykh Differential Revision: D17203240 fbshipit-source-id: c809857ed
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.setNullableToNotNullableIsBAD(java.lang.String):void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotNullable.notNullable` can be null but is not declared `@Nullable`. (Origin: method parameter s)]
[nullsafe] Consolidate and expand tests for known initializers Summary: 1. Let's move it to the file dedicated to this particular warning. 2. Make it more general (Activity was just a particular case) and describe in comments what it really does. Reviewed By: ngorogiannis Differential Revision: D17205919 fbshipit-source-id: 82bf5e9bd
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.setNullableToNotNullableIsBAD(java.lang.String):void, 3, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `FieldNotNullable.notNullable` can be null but is not declared `@Nullable`. (Origin: call to getNullable() at line 67)]
[nullsafe] Add a test for field-overannotated warning Summary: Turns out, we did not have such a test in place. Known issue: we report over-annotated warnings for each fields N times, one per constructor, which is wrong. Reviewed By: artempyanykh Differential Revision: D17574791 fbshipit-source-id: def992691
5 years ago
codetoanalyze/java/nullsafe-default/FieldOverAnnotated.java, codetoanalyze.java.nullsafe_default.FieldOverAnnotated.<init>(int), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldOverAnnotated.FP_initializedInAllConstructorsButSetToNullInAPublicMethodShouldBeOK` is always initialized in the constructor but is declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldOverAnnotated.java, codetoanalyze.java.nullsafe_default.FieldOverAnnotated.<init>(int), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldOverAnnotated.initializedInAllConstructorsIsBAD` is always initialized in the constructor but is declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldOverAnnotated.java, codetoanalyze.java.nullsafe_default.FieldOverAnnotated.<init>(int), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldOverAnnotated.initilizedInAllConstructorsAndAllBranchesIsBAD` is always initialized in the constructor but is declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldOverAnnotated.java, codetoanalyze.java.nullsafe_default.FieldOverAnnotated.<init>(int,int), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldOverAnnotated.FP_initializedInAllConstructorsButSetToNullInAPublicMethodShouldBeOK` is always initialized in the constructor but is declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldOverAnnotated.java, codetoanalyze.java.nullsafe_default.FieldOverAnnotated.<init>(int,int), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldOverAnnotated.initializedInAllConstructorsIsBAD` is always initialized in the constructor but is declared `@Nullable`]
codetoanalyze/java/nullsafe-default/FieldOverAnnotated.java, codetoanalyze.java.nullsafe_default.FieldOverAnnotated.<init>(int,int), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `FieldOverAnnotated.initilizedInAllConstructorsAndAllBranchesIsBAD` is always initialized in the constructor but is declared `@Nullable`]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/InconsistentSubclassAnnotation.java, codetoanalyze.java.nullsafe_default.ExtendsExternalLibrary.externalMethod2(java.lang.Object):void, 0, ERADICATE_INCONSISTENT_SUBCLASS_PARAMETER_ANNOTATION, no_bucket, WARNING, [First parameter `object` of method `ExtendsExternalLibrary.externalMethod2(...)` is not `@Nullable` but is declared `@Nullable`in the parent class method `SomeExternalClass.externalMethod2(...)`.]
codetoanalyze/java/nullsafe-default/InconsistentSubclassAnnotation.java, codetoanalyze.java.nullsafe_default.InconsistentSubclassAnnotation.implementInAnotherFile(java.lang.String):java.lang.String, 0, ERADICATE_INCONSISTENT_SUBCLASS_PARAMETER_ANNOTATION, no_bucket, WARNING, [First parameter `s` of method `InconsistentSubclassAnnotation.implementInAnotherFile(...)` is not `@Nullable` but is declared `@Nullable`in the parent class method `InconsistentSubclassAnnotationInterface.implementInAnotherFile(...)`.]
codetoanalyze/java/nullsafe-default/InconsistentSubclassAnnotation.java, codetoanalyze.java.nullsafe_default.InconsistentSubclassAnnotation.overloadedMethod():java.lang.Object, 0, ERADICATE_INCONSISTENT_SUBCLASS_RETURN_ANNOTATION, no_bucket, WARNING, [Method `InconsistentSubclassAnnotation.overloadedMethod()` is annotated with `@Nullable` but overrides unannotated method `InconsistentSubclassAnnotationInterface.overloadedMethod()`.]
codetoanalyze/java/nullsafe-default/InconsistentSubclassAnnotation.java, codetoanalyze.java.nullsafe_default.Sub.overloadingMethodLookupFP(java.lang.Object):java.lang.String, 0, ERADICATE_INCONSISTENT_SUBCLASS_RETURN_ANNOTATION, no_bucket, WARNING, [Method `Sub.overloadingMethodLookupFP(...)` is annotated with `@Nullable` but overrides unannotated method `Super.overloadingMethodLookupFP(...)`.]
codetoanalyze/java/nullsafe-default/InconsistentSubclassAnnotation.java, codetoanalyze.java.nullsafe_default.SubclassExample$B.foo():codetoanalyze.java.nullsafe_default.SubclassExample$T, 0, ERADICATE_INCONSISTENT_SUBCLASS_RETURN_ANNOTATION, no_bucket, WARNING, [Method `SubclassExample$B.foo()` is annotated with `@Nullable` but overrides unannotated method `SubclassExample$A.foo()`.]
codetoanalyze/java/nullsafe-default/InconsistentSubclassAnnotation.java, codetoanalyze.java.nullsafe_default.SubclassExample$C.baz():codetoanalyze.java.nullsafe_default.SubclassExample$T, 0, ERADICATE_INCONSISTENT_SUBCLASS_RETURN_ANNOTATION, no_bucket, WARNING, [Method `SubclassExample$C.baz()` is annotated with `@Nullable` but overrides unannotated method `SubclassExample$I.baz()`.]
codetoanalyze/java/nullsafe-default/InconsistentSubclassAnnotation.java, codetoanalyze.java.nullsafe_default.SubclassExample$D.deref(codetoanalyze.java.nullsafe_default.SubclassExample$T):void, 0, ERADICATE_INCONSISTENT_SUBCLASS_PARAMETER_ANNOTATION, no_bucket, WARNING, [First parameter `t` of method `SubclassExample$D.deref(...)` is not `@Nullable` but is declared `@Nullable`in the parent class method `SubclassExample$A.deref(...)`.]
[nullsafe] Consolidate various things checking dereference and get rid of misleading names Summary: The current usage has several issues reducing code maintainability and readability: 1. Null_field_access was misleading: it was used for checking accesing to arrays as well! 2. But actually, when checking access to array via `length`, we sometimes pretended it is a field access (hence very tricky code in rendering the error). 3. "Call receiver consistency" is unclear name, was not obvious that it is all about calling a method in an object. Let's also consolidate code. Reviewed By: artempyanykh Differential Revision: D17789618 fbshipit-source-id: 9b0f58c9c
5 years ago
codetoanalyze/java/nullsafe-default/LibraryCalls.java, codetoanalyze.java.nullsafe_default.LibraryCalls.badAtomicReferenceDereference(java.util.concurrent.atomic.AtomicReference):java.lang.String, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ref.get()` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get() modelled in modelTables.ml at line 35)]
codetoanalyze/java/nullsafe-default/LibraryCalls.java, codetoanalyze.java.nullsafe_default.LibraryCalls.badPhantomReferenceDereference(java.lang.ref.PhantomReference):java.lang.String, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ref.get()` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get() modelled in modelTables.ml at line 27)]
codetoanalyze/java/nullsafe-default/LibraryCalls.java, codetoanalyze.java.nullsafe_default.LibraryCalls.badReferenceDereference(java.lang.ref.Reference):java.lang.String, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ref.get()` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get() modelled in modelTables.ml at line 19)]
codetoanalyze/java/nullsafe-default/LibraryCalls.java, codetoanalyze.java.nullsafe_default.LibraryCalls.badSoftReferenceDereference(java.lang.ref.SoftReference):java.lang.String, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ref.get()` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get() modelled in modelTables.ml at line 31)]
codetoanalyze/java/nullsafe-default/LibraryCalls.java, codetoanalyze.java.nullsafe_default.LibraryCalls.badWeakReferenceDereference(java.lang.ref.WeakReference):java.lang.String, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ref.get()` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get() modelled in modelTables.ml at line 23)]
[nullsafe][refactor tests] split and improve FieldNotNullable tests Summary: See motivation below. This diff is dealing with FieldNotNullable: - move not relevant subclasses into dedicated classes and files - modify the tests so they comply with the standards below --Motivation-- Gradual mode we are going to introduce is an invasive change in how Infer treats nullability semantics. In order to make the change in a controllable way, we need the tests to comply with the following standards and conventions. 1. For each code peace where we expect a bug to happen, the there should be corresponding (minimally different from above) peace of code where we expect a bug to NOT happen. (This is to ensure bug is happening for exact reason we think it is happening). 2. Conversely: for each peace of code where we expect a bug to be NOT present, there shuold be a peace of code where the bug IS happening. (Otherwise there can be too many reasons for a bug NOT to happen). 3. Convention: end corresponding methods IsOK and IsBUG correspondingly. 4. Keep code examples as small as possible. Reviewed By: ngorogiannis Differential Revision: D17183222 fbshipit-source-id: 83d03e67f
5 years ago
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.getAfterConditionalPutWrongKeyIsBAD(java.util.Map,java.lang.String,java.lang.String):void, 5, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `MapNullability$TestThatGetAfterPutIsAllowed.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to get(...) modelled in modelTables.ml at line 137)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.getAfterPutNullableIsBAD(java.util.Map,java.lang.String):void, 2, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`Map.put(...)` needs a non-null value in parameter 2 but argument `nullableValue` can be null.]
[nullsafe][refactor tests] split and improve FieldNotNullable tests Summary: See motivation below. This diff is dealing with FieldNotNullable: - move not relevant subclasses into dedicated classes and files - modify the tests so they comply with the standards below --Motivation-- Gradual mode we are going to introduce is an invasive change in how Infer treats nullability semantics. In order to make the change in a controllable way, we need the tests to comply with the following standards and conventions. 1. For each code peace where we expect a bug to happen, the there should be corresponding (minimally different from above) peace of code where we expect a bug to NOT happen. (This is to ensure bug is happening for exact reason we think it is happening). 2. Conversely: for each peace of code where we expect a bug to be NOT present, there shuold be a peace of code where the bug IS happening. (Otherwise there can be too many reasons for a bug NOT to happen). 3. Convention: end corresponding methods IsOK and IsBUG correspondingly. 4. Keep code examples as small as possible. Reviewed By: ngorogiannis Differential Revision: D17183222 fbshipit-source-id: 83d03e67f
5 years ago
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.getAfterPutNullableIsBAD(java.util.Map,java.lang.String):void, 3, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `MapNullability$TestThatGetAfterPutIsAllowed.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: method parameter nullableValue)]
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.getAfterPutSeveralKeysButGetWrongOneIsBAD(java.util.Map):void, 4, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `MapNullability$TestThatGetAfterPutIsAllowed.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to get(...) modelled in modelTables.ml at line 98)]
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.getAfterPutWrongKeyIsBAD(java.util.Map,java.lang.String,java.lang.String):void, 3, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `MapNullability$TestThatGetAfterPutIsAllowed.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to get(...) modelled in modelTables.ml at line 79)]
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.getWithoutPutIsBAD(java.util.Map,java.lang.String):void, 1, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `MapNullability$TestThatGetAfterPutIsAllowed.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to get(...) modelled in modelTables.ml at line 73)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.overwriteKeyByNonnullIsOK(java.util.Map,java.lang.String):void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`Map.put(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.overwriteKeyByNullIsBAD(java.util.Map,java.lang.String):void, 2, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`Map.put(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
[nullsafe][refactor tests] split and improve FieldNotNullable tests Summary: See motivation below. This diff is dealing with FieldNotNullable: - move not relevant subclasses into dedicated classes and files - modify the tests so they comply with the standards below --Motivation-- Gradual mode we are going to introduce is an invasive change in how Infer treats nullability semantics. In order to make the change in a controllable way, we need the tests to comply with the following standards and conventions. 1. For each code peace where we expect a bug to happen, the there should be corresponding (minimally different from above) peace of code where we expect a bug to NOT happen. (This is to ensure bug is happening for exact reason we think it is happening). 2. Conversely: for each peace of code where we expect a bug to be NOT present, there shuold be a peace of code where the bug IS happening. (Otherwise there can be too many reasons for a bug NOT to happen). 3. Convention: end corresponding methods IsOK and IsBUG correspondingly. 4. Keep code examples as small as possible. Reviewed By: ngorogiannis Differential Revision: D17183222 fbshipit-source-id: 83d03e67f
5 years ago
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetAfterPutIsAllowed.overwriteKeyByNullIsBAD(java.util.Map,java.lang.String):void, 3, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `MapNullability$TestThatGetAfterPutIsAllowed.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: null constant at line 114)]
[nullsafe] Consolidate various things checking dereference and get rid of misleading names Summary: The current usage has several issues reducing code maintainability and readability: 1. Null_field_access was misleading: it was used for checking accesing to arrays as well! 2. But actually, when checking access to array via `length`, we sometimes pretended it is a field access (hence very tricky code in rendering the error). 3. "Call receiver consistency" is unclear name, was not obvious that it is all about calling a method in an object. Let's also consolidate code. Reviewed By: artempyanykh Differential Revision: D17789618 fbshipit-source-id: 9b0f58c9c
5 years ago
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetIsAllowedOnlyAfterContainsKeyWasChecked.immutableMap_usingGetAfterWrongKeyWasCheckedIsBAD(com.google.common.collect.ImmutableMap):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`m.get(...)` is nullable and is not locally checked for null when calling `isEmpty()`. (Origin: call to get(...) modelled in modelTables.ml at line 59)]
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetIsAllowedOnlyAfterContainsKeyWasChecked.usingGetAfterWrongKeyWasCheckedInWhileLoopIsBAD(java.util.Map):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`m.get(...)` is nullable and is not locally checked for null when calling `isEmpty()`. (Origin: call to get(...) modelled in modelTables.ml at line 44)]
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetIsAllowedOnlyAfterContainsKeyWasChecked.usingGetAfterWrongKeyWasCheckedIsBAD(java.util.Map):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`m.get(...)` is nullable and is not locally checked for null when calling `isEmpty()`. (Origin: call to get(...) modelled in modelTables.ml at line 29)]
codetoanalyze/java/nullsafe-default/MapNullability.java, codetoanalyze.java.nullsafe_default.MapNullability$TestThatGetIsAllowedOnlyAfterContainsKeyWasChecked.usingGetWithoutCheckingKeyIsBAD(java.util.Map):void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`m.get(...)` is nullable and is not locally checked for null when calling `isEmpty()`. (Origin: call to get(...) modelled in modelTables.ml at line 24)]
[nullsafe][refactor tests] split and improve FieldNotNullable tests Summary: See motivation below. This diff is dealing with FieldNotNullable: - move not relevant subclasses into dedicated classes and files - modify the tests so they comply with the standards below --Motivation-- Gradual mode we are going to introduce is an invasive change in how Infer treats nullability semantics. In order to make the change in a controllable way, we need the tests to comply with the following standards and conventions. 1. For each code peace where we expect a bug to happen, the there should be corresponding (minimally different from above) peace of code where we expect a bug to NOT happen. (This is to ensure bug is happening for exact reason we think it is happening). 2. Conversely: for each peace of code where we expect a bug to be NOT present, there shuold be a peace of code where the bug IS happening. (Otherwise there can be too many reasons for a bug NOT to happen). 3. Convention: end corresponding methods IsOK and IsBUG correspondingly. 4. Keep code examples as small as possible. Reviewed By: ngorogiannis Differential Revision: D17183222 fbshipit-source-id: 83d03e67f
5 years ago
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.chainOf0VsChainOf0ParamsMismatchIsBad():void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 145)]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.chainOf0VsChainOf1IsBad():void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 169)]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.chainOf1VsChainOf0IsBad():void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 175)]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.chainOf1VsChainOf1ParamMismatchIsBad():void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 187)]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.chainOf1VsChainOf2IsBad():void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 199)]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.chainOf2VsChainOf1IsBad():void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 205)]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.otherObjVsItselfIsOKParamsMismatchIsBAD(codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent):void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 157)]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent.selfVsOtherObjectIsBAD(codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestFunctionsIdempotent):void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [Field `NestedFieldAccess$TestFunctionsIdempotent.dontAssignNull` can be null but is not declared `@Nullable`. (Origin: call to nullable(...) at line 163)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestNullableChains.deep_AccessWithoutNullCheckIsBad(codetoanalyze.java.nullsafe_default.NestedFieldAccess$CC):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`cc.c.s` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestNullableChains.field_AccessWithoutNullCheckIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`NestedFieldAccess$TestNullableChains.s` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestNullableChains.local_AccessWithoutNullCheckIsBad():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`c.s` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestNullableChains.nestedField_AccessWithoutNullCheckIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`NestedFieldAccess$TestNullableChains.myc.s` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestNullableChains.param_AccessWithoutNullCheckIsBad(codetoanalyze.java.nullsafe_default.NestedFieldAccess$C):void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`c.s` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestNullableChains.veryDeep_AccessWithoutNullCheckIsBad(codetoanalyze.java.nullsafe_default.NestedFieldAccess$CCC):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ccc.cc.c.s` is nullable and is not locally checked for null when calling `length()`.]
codetoanalyze/java/nullsafe-default/NestedFieldAccess.java, codetoanalyze.java.nullsafe_default.NestedFieldAccess$TestNullableChains.veryDeep_IncompleteAccessViaOrEarlyReturnIsBad(codetoanalyze.java.nullsafe_default.NestedFieldAccess$CCC):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`ccc.cc.c.s` is nullable and is not locally checked for null when calling `length()`.]
[nullsafe] Add a test for field-overannotated warning Summary: Turns out, we did not have such a test in place. Known issue: we report over-annotated warnings for each fields N times, one per constructor, which is wrong. Reviewed By: artempyanykh Differential Revision: D17574791 fbshipit-source-id: def992691
5 years ago
codetoanalyze/java/nullsafe-default/NullFieldAccess.java, codetoanalyze.java.nullsafe_default.NullFieldAccess.<init>(), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `NullFieldAccess.nullable` is always initialized in the constructor but is declared `@Nullable`]
codetoanalyze/java/nullsafe-default/NullFieldAccess.java, codetoanalyze.java.nullsafe_default.NullFieldAccess.<init>(), 0, ERADICATE_FIELD_OVER_ANNOTATED, no_bucket, WARNING, [Field `NullFieldAccess.nullableArray` is always initialized in the constructor but is declared `@Nullable`]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/NullFieldAccess.java, codetoanalyze.java.nullsafe_default.NullFieldAccess.testArray():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [Array `NullFieldAccess.nullableArray` is nullable and is not locally checked for null when accessing its length.]
codetoanalyze/java/nullsafe-default/NullFieldAccess.java, codetoanalyze.java.nullsafe_default.NullFieldAccess.testArray():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [Array `NullFieldAccess.nullableArray` is nullable and is not locally checked for null when accessing at index `0`.]
[nullsafe] Consolidate various things checking dereference and get rid of misleading names Summary: The current usage has several issues reducing code maintainability and readability: 1. Null_field_access was misleading: it was used for checking accesing to arrays as well! 2. But actually, when checking access to array via `length`, we sometimes pretended it is a field access (hence very tricky code in rendering the error). 3. "Call receiver consistency" is unclear name, was not obvious that it is all about calling a method in an object. Let's also consolidate code. Reviewed By: artempyanykh Differential Revision: D17789618 fbshipit-source-id: 9b0f58c9c
5 years ago
codetoanalyze/java/nullsafe-default/NullFieldAccess.java, codetoanalyze.java.nullsafe_default.NullFieldAccess.testInterface():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`bad` is nullable and is not locally checked for null when calling `toString()`. (Origin: field NullFieldAccess$I.nullable at line 52)]
codetoanalyze/java/nullsafe-default/NullFieldAccess.java, codetoanalyze.java.nullsafe_default.NullFieldAccess.testNonStaticFields():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`bad` is nullable and is not locally checked for null when calling `toString()`. (Origin: field NullFieldAccess.nullable at line 36)]
codetoanalyze/java/nullsafe-default/NullFieldAccess.java, codetoanalyze.java.nullsafe_default.NullFieldAccess.testStatic():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`bad` is nullable and is not locally checked for null when calling `toString()`. (Origin: field NullFieldAccess.nullableStatic at line 44)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall$Inner.outerField():int, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `length()`. (Origin: field NullMethodCall.fld at line 69)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall$Inner.outerPrivateField():int, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `length()`. (Origin: field NullMethodCall.pfld at line 80)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.FP_propagatesNonNullAfterComparisonFieldOkay(java.lang.Object):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`NullMethodCall.nullableField` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.FP_propagatesNonNullAfterComparisonParameterOkay(java.lang.Object,java.lang.Object):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`nullableParameter` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Consolidate various things checking dereference and get rid of misleading names Summary: The current usage has several issues reducing code maintainability and readability: 1. Null_field_access was misleading: it was used for checking accesing to arrays as well! 2. But actually, when checking access to array via `length`, we sometimes pretended it is a field access (hence very tricky code in rendering the error). 3. "Call receiver consistency" is unclear name, was not obvious that it is all about calling a method in an object. Let's also consolidate code. Reviewed By: artempyanykh Differential Revision: D17789618 fbshipit-source-id: 9b0f58c9c
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.callOnNull():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `length()`. (Origin: null constant at line 25)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.callingSeverSideNullableGetter(codetoanalyze.java.nullsafe_default.ServerSideDeserializer):java.lang.String, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, ERROR, [`deserializer.nullableGetter()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.nullMethodCallWithAlarmManager(android.app.AlarmManager,android.app.PendingIntent):void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`AlarmManager.cancel(...)` needs a non-null value in parameter 1 but argument `intent` can be null.]
[nullsafe] Consolidate various things checking dereference and get rid of misleading names Summary: The current usage has several issues reducing code maintainability and readability: 1. Null_field_access was misleading: it was used for checking accesing to arrays as well! 2. But actually, when checking access to array via `length`, we sometimes pretended it is a field access (hence very tricky code in rendering the error). 3. "Call receiver consistency" is unclear name, was not obvious that it is all about calling a method in an object. Let's also consolidate code. Reviewed By: artempyanykh Differential Revision: D17789618 fbshipit-source-id: 9b0f58c9c
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.nullabilityNotPreservedAfterAssignment():void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`t` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to getNullable() at line 340)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.nullabilityStoredInBooleanFP():void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`getNullable()` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Consolidate various things checking dereference and get rid of misleading names Summary: The current usage has several issues reducing code maintainability and readability: 1. Null_field_access was misleading: it was used for checking accesing to arrays as well! 2. But actually, when checking access to array via `length`, we sometimes pretended it is a field access (hence very tricky code in rendering the error). 3. "Call receiver consistency" is unclear name, was not obvious that it is all about calling a method in an object. Let's also consolidate code. Reviewed By: artempyanykh Differential Revision: D17789618 fbshipit-source-id: 9b0f58c9c
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testExceptionPerInstruction(int):void, 6, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `length()`. (Origin: null constant at line 181)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testFieldAssignmentIfThenElse(java.lang.String):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `length()`. (Origin: null constant at line 172)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testInAssignmentFP(java.lang.Object):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`t` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to getNullable() at line 354)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testMapGetBad(java.util.Map,java.util.HashMap,java.util.concurrent.ConcurrentHashMap):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`m.get(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get(...) modelled in modelTables.ml at line 260)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testMapGetBad(java.util.Map,java.util.HashMap,java.util.concurrent.ConcurrentHashMap):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`hm.get(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get(...) modelled in modelTables.ml at line 261)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testMapGetBad(java.util.Map,java.util.HashMap,java.util.concurrent.ConcurrentHashMap):void, 4, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`chm.get(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to get(...) modelled in modelTables.ml at line 262)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testMapRemoveBad(java.util.Map,java.util.HashMap,java.util.concurrent.ConcurrentHashMap):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`m.remove(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to remove(...) modelled in modelTables.ml at line 267)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testMapRemoveBad(java.util.Map,java.util.HashMap,java.util.concurrent.ConcurrentHashMap):void, 3, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`hm.remove(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to remove(...) modelled in modelTables.ml at line 268)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testMapRemoveBad(java.util.Map,java.util.HashMap,java.util.concurrent.ConcurrentHashMap):void, 4, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`chm.remove(...)` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to remove(...) modelled in modelTables.ml at line 269)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testNotDetectingInvariantFP(java.lang.Object,java.lang.Object):java.lang.String, 4, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`object2` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Consolidate various things checking dereference and get rid of misleading names Summary: The current usage has several issues reducing code maintainability and readability: 1. Null_field_access was misleading: it was used for checking accesing to arrays as well! 2. But actually, when checking access to array via `length`, we sometimes pretended it is a field access (hence very tricky code in rendering the error). 3. "Call receiver consistency" is unclear name, was not obvious that it is all about calling a method in an object. Let's also consolidate code. Reviewed By: artempyanykh Differential Revision: D17789618 fbshipit-source-id: 9b0f58c9c
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testPathGetParent():java.lang.String, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`get(...).getParent()` is nullable and is not locally checked for null when calling `toString()`. (Origin: call to getParent() modelled in modelTables.ml at line 360)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testSystemGetPropertyReturn():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`s` is nullable and is not locally checked for null when calling `length()`. (Origin: call to getProperty(...) modelled in modelTables.ml at line 235)]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.testSystemGetenvBad():int, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`envValue` is nullable and is not locally checked for null when calling `length()`. (Origin: call to getenv(...) modelled in modelTables.ml at line 240)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.withConditionalAssignemnt(codetoanalyze.java.nullsafe_default.NullMethodCall$AnotherI,boolean,java.lang.Object,java.lang.Object):void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`i` is nullable and is not locally checked for null when calling `withObjectParameter(...)`.]
codetoanalyze/java/nullsafe-default/NullMethodCall.java, codetoanalyze.java.nullsafe_default.NullMethodCall.withConjuction(codetoanalyze.java.nullsafe_default.NullMethodCall$AnotherI,boolean,boolean):void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`i` is nullable and is not locally checked for null when calling `withBooleanParameter(...)`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable$ConstructorCall.<init>(codetoanalyze.java.nullsafe_default.ParameterNotNullable,int), 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable$ConstructorCall(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.callNull():void, 2, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.test(...)` needs a non-null value in parameter 1 but argument `s` can be null. (Origin: null constant at line 39)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.callNullable(java.lang.String):void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.test(...)` needs a non-null value in parameter 1 but argument `s` can be null.]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.callWithConditionalAssignment(java.lang.Object,boolean):void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.doesNotAcceptNullableFirstParameter(...)` needs a non-null value in parameter 1 but argument `object` can be null. (Origin: null constant at line 116)]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.callWithNullableFirstParameter(boolean,boolean):void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.doesNotAcceptNullableFirstParameter(...)` needs a non-null value in parameter 1 but argument `formal parameter object` can be null. (Origin: null constant at line 112)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testClassGetResourceArgument(java.lang.Class):java.net.URL, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`Class.getResource(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListCopyOfNotNullArguments():void, 6, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.copyOf(...)` needs a non-null value in parameter 1 but argument `nullIterable` can be null. (Origin: null constant at line 131)]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListCopyOfNotNullArguments():void, 7, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.copyOf(...)` needs a non-null value in parameter 1 but argument `nullIterator` can be null. (Origin: null constant at line 132)]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListCopyOfNotNullArguments():void, 8, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.copyOf(...)` needs a non-null value in parameter 1 but argument `nullCollection` can be null. (Origin: null constant at line 133)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListOfnotNullArguments():void, 4, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.of(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.of(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.of(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListOfnotNullArguments():void, 7, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.of(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListSortedCopyOfNotNullArguments():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.sortedCopyOf(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListSortedCopyOfNotNullArguments():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.sortedCopyOf(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapCopyOfNotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.copyOf(...)` needs a non-null value in parameter 1 but argument `nullIterable` can be null. (Origin: null constant at line 177)]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapCopyOfNotNullArguments():void, 6, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.copyOf(...)` needs a non-null value in parameter 1 but argument `nullMap` can be null. (Origin: null constant at line 178)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapOfnotNullArguments():void, 4, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.of(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapOfnotNullArguments():void, 4, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.of(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapOfnotNullArguments():void, 6, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.of(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapOfnotNullArguments():void, 6, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.of(...)` needs a non-null value in parameter 4 but argument `null` can be null.]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetCopyOfNotNullArguments():void, 6, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.copyOf(...)` needs a non-null value in parameter 1 but argument `nullIterable` can be null. (Origin: null constant at line 157)]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetCopyOfNotNullArguments():void, 7, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.copyOf(...)` needs a non-null value in parameter 1 but argument `nullIterator` can be null. (Origin: null constant at line 158)]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetCopyOfNotNullArguments():void, 8, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.copyOf(...)` needs a non-null value in parameter 1 but argument `nullCollection` can be null. (Origin: null constant at line 159)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 4, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 7, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 8, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 8, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)` needs a non-null value in parameter 4 but argument `null` can be null.]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testParsingNullStringToNumber():void, 2, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`Long.parseLong(...)` needs a non-null value in parameter 1 but argument `ns` can be null. (Origin: null constant at line 185)]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testParsingNullStringToNumber():void, 3, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`Integer.parseInt(...)` needs a non-null value in parameter 1 but argument `ns` can be null. (Origin: null constant at line 185)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testSystemGetPropertyArgument():java.lang.String, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`System.getProperty(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testSystemGetenvBad():java.lang.String, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`System.getenv(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testThreeParameters():void, 2, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.threeParameters(...)` needs a non-null value in parameter 1 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testThreeParameters():void, 3, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.threeParameters(...)` needs a non-null value in parameter 2 but argument `null` can be null.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testThreeParameters():void, 4, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.threeParameters(...)` needs a non-null value in parameter 3 but argument `null` can be null.]
[nullsafe][easy] Remove duplicated test cases for condition redundant Summary: D17397144 adds dedicated tests for condition redundant. We also have tests for overannotated methods. This makes these test cases redundant. Let's not pollute the results. Reviewed By: jberdine Differential Revision: D17398757 fbshipit-source-id: 10f6beeca
5 years ago
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable$ConditionalAssignment.test(boolean):java.lang.Object, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `test(...)` may return null but it is not annotated with `@Nullable`. (Origin: field ReturnNotNullable$ConditionalAssignment.f1 at line 199)]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.constantToNullableIsOverannotated():java.lang.String, 0, ERADICATE_RETURN_OVER_ANNOTATED, no_bucket, WARNING, [Method `constantToNullableIsOverannotated()` is annotated with `@Nullable` but never returns null.]
[nullsafe][easy] Remove duplicated test cases for condition redundant Summary: D17397144 adds dedicated tests for condition redundant. We also have tests for overannotated methods. This makes these test cases redundant. Let's not pollute the results. Reviewed By: jberdine Differential Revision: D17398757 fbshipit-source-id: 10f6beeca
5 years ago
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.getResourceNullable(java.lang.Class,java.lang.String):java.net.URL, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `getResourceNullable(...)` may return null but it is not annotated with `@Nullable`. (Origin: call to getResource(...) modelled in modelTables.ml at line 177)]
[nullsafe] Prepare to introduce gradual mode: split tests Summary: In next diff, we are going to introduce a new mode of nullsafe (gradual). For testing, we are going to employ the strategy used by jvillard for Pulse. In this diff we split tests into two subfolders, one for the default and one for the gradual mode. We are planning to make the gradual mode default eventually. For that, most new features will make sense for gradual mode, and we will mostly evolve tests for that mode. As for 'default' mode, we need to preserve tests mostly to ensure we don't introduce regressions. Occasionally, we might make changes that make sense for both modes, in this (expected relatively rare) cases we will make changes to both set of tests. An alternative strategy would be to have two sets of issues.exp files, one for gradual and one for default mode. This has an advantage of each java file to be always tested twice, but disadvantage is that it will be harder to write meaningful test code so that it makes sense for both modes simultaneously. Reviewed By: ngorogiannis Differential Revision: D17156724 fbshipit-source-id: a92a9208f
5 years ago
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.nonNullToNullableIsOverannotated(java.lang.String):java.lang.String, 0, ERADICATE_RETURN_OVER_ANNOTATED, no_bucket, WARNING, [Method `nonNullToNullableIsOverannotated(...)` is annotated with `@Nullable` but never returns null.]
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.notAnnotatedNullableIsOverannotated(java.lang.String):java.lang.String, 0, ERADICATE_RETURN_OVER_ANNOTATED, no_bucket, WARNING, [Method `notAnnotatedNullableIsOverannotated(...)` is annotated with `@Nullable` but never returns null.]
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.nullToNonnullIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `nullToNonnullIsBad()` may return null but it is not annotated with `@Nullable`. (Origin: null constant at line 60)]
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.nullToNotAnnotatedIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `nullToNotAnnotatedIsBad()` may return null but it is not annotated with `@Nullable`. (Origin: null constant at line 35)]
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.nullableToNonnullIsBad(java.lang.String):java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `nullableToNonnullIsBad(...)` may return null but it is not annotated with `@Nullable`. (Origin: method parameter s)]
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.nullableToNotAnnotatedIsBad(java.lang.String):java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `nullableToNotAnnotatedIsBad(...)` may return null but it is not annotated with `@Nullable`. (Origin: method parameter s)]
[nullsafe][easy] Remove duplicated test cases for condition redundant Summary: D17397144 adds dedicated tests for condition redundant. We also have tests for overannotated methods. This makes these test cases redundant. Let's not pollute the results. Reviewed By: jberdine Differential Revision: D17398757 fbshipit-source-id: 10f6beeca
5 years ago
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.return_null_in_catch():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `return_null_in_catch()` may return null but it is not annotated with `@Nullable`. (Origin: null constant at line 160)]
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.return_null_in_catch_after_throw():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `return_null_in_catch_after_throw()` may return null but it is not annotated with `@Nullable`. (Origin: null constant at line 172)]
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.tryWithResourcesReturnNullable(java.lang.String):java.lang.Object, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `tryWithResourcesReturnNullable(...)` may return null but it is not annotated with `@Nullable`. (Origin: call to nullToNullableIsOK() at line 142)]
[nullsafe] Primitive types are always Nonnull Summary: Primitive types are not annotated. Because of that, we used to implicitly derive `DeclaredNonnull` type for them. This worked fine, but this leads to errors in Strict mode, which does not believe DeclaredNonnull type. Now lets offifically teach nullsafe that primitive types are non-nullable. Reviewed By: jvillard Differential Revision: D18114623 fbshipit-source-id: 227217931
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_convertingNonnullToNonnullIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `nonStrictClass_convertingNonnullToNonnullIsBad()` may return null but it is not annotated with `@Nullable`. (Origin: call to getNonnull() at line 146)]
[nullsafe] Introduce Strict mode Summary: This is the first take on strict mode semantics. The main invariant of strict mode is the following: If the function passes `NullsafeStrict` check and its return value is NOT annotated as Nullable, then the function does not indeed return nulls, subject to unsoundness issues (which should either be fixed, or should rarely happen in practice). This invariant helps the caller in two ways: 1. Dangerous usages of non strict functions are visible, so the caller is enforced to check them (via assertions or conditions), or strictify them. 2. When the function is strict, the caller does not need to worry about being defensive. Biggest known issues so far: 1. Condition redundant and over-annotated warnings don't fully respect strict mode, and this leads to stupid false positives. (There is so much more stupid false positives in condition redundant anyway, so not particularly a big deal for now). 2. Error reporting is not specific to mode. (E.g. we don't distinct real nullables and non-trusted non-nulls, which can be misleading). To be improved as a follow up. Reviewed By: artempyanykh Differential Revision: D17978166 fbshipit-source-id: d6146ad71
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_convertingNonnullToNullableIsOK():java.lang.String, 0, ERADICATE_RETURN_OVER_ANNOTATED, no_bucket, WARNING, [Method `nonStrictClass_convertingNonnullToNullableIsOK()` is annotated with `@Nullable` but never returns null.]
[nullsafe] Make Strict mode respect static methods Summary: The wrong function was used when we tried to see if the class is annotated with NullsafeStrict. This made it work only for non-static methods. Now we use the proper way. Reviewed By: ngorogiannis Differential Revision: D18113848 fbshipit-source-id: 02b7555be
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_convertingNullableToNonnullIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `nonStrictClass_convertingNullableToNonnullIsBad()` may return null but it is not annotated with `@Nullable`. (Origin: call to getNullable() at line 135)]
[nullsafe] Introduce Strict mode Summary: This is the first take on strict mode semantics. The main invariant of strict mode is the following: If the function passes `NullsafeStrict` check and its return value is NOT annotated as Nullable, then the function does not indeed return nulls, subject to unsoundness issues (which should either be fixed, or should rarely happen in practice). This invariant helps the caller in two ways: 1. Dangerous usages of non strict functions are visible, so the caller is enforced to check them (via assertions or conditions), or strictify them. 2. When the function is strict, the caller does not need to worry about being defensive. Biggest known issues so far: 1. Condition redundant and over-annotated warnings don't fully respect strict mode, and this leads to stupid false positives. (There is so much more stupid false positives in condition redundant anyway, so not particularly a big deal for now). 2. Error reporting is not specific to mode. (E.g. we don't distinct real nullables and non-trusted non-nulls, which can be misleading). To be improved as a follow up. Reviewed By: artempyanykh Differential Revision: D17978166 fbshipit-source-id: d6146ad71
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNonnullFieldAfterCheckIsOK():void, 2, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition NonStrict.nonnull is always true according to the existing annotations.]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNonnullFieldIsBad():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`__new(...).nonnull` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Introduce Strict mode Summary: This is the first take on strict mode semantics. The main invariant of strict mode is the following: If the function passes `NullsafeStrict` check and its return value is NOT annotated as Nullable, then the function does not indeed return nulls, subject to unsoundness issues (which should either be fixed, or should rarely happen in practice). This invariant helps the caller in two ways: 1. Dangerous usages of non strict functions are visible, so the caller is enforced to check them (via assertions or conditions), or strictify them. 2. When the function is strict, the caller does not need to worry about being defensive. Biggest known issues so far: 1. Condition redundant and over-annotated warnings don't fully respect strict mode, and this leads to stupid false positives. (There is so much more stupid false positives in condition redundant anyway, so not particularly a big deal for now). 2. Error reporting is not specific to mode. (E.g. we don't distinct real nullables and non-trusted non-nulls, which can be misleading). To be improved as a follow up. Reviewed By: artempyanykh Differential Revision: D17978166 fbshipit-source-id: d6146ad71
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNonnullMethodAfterCheckIsOK():void, 2, ERADICATE_CONDITION_REDUNDANT, no_bucket, WARNING, [The condition lang.String(o)V is always true according to the existing annotations.]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNonnullMethodIsBad():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`__new(...).getNonnull()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNonnullStaticMethodIsBad():void, 2, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`staticNonnull()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNullableFieldIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`__new(...).nullable` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNullableMethodIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`__new(...).getNullable()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_dereferenceNullableStaticMethodIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`staticNullable()` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Make Strict mode respect static methods Summary: The wrong function was used when we tried to see if the class is annotated with NullsafeStrict. This made it work only for non-static methods. Now we use the proper way. Reviewed By: ngorogiannis Differential Revision: D18113848 fbshipit-source-id: 02b7555be
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.sameClass_convertingNullableToNonnullIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `sameClass_convertingNullableToNonnullIsBad()` may return null but it is not annotated with `@Nullable`. (Origin: call to getNullable() at line 63)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.sameClass_dereferenceNullableFieldIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`Strict.nullable` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.sameClass_dereferenceNullableMethodIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`getNullable()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.sameClass_dereferenceNullableStaticMethodIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`staticNullable()` is nullable and is not locally checked for null when calling `toString()`.]
[nullsafe] Make Strict mode respect static methods Summary: The wrong function was used when we tried to see if the class is annotated with NullsafeStrict. This made it work only for non-static methods. Now we use the proper way. Reviewed By: ngorogiannis Differential Revision: D18113848 fbshipit-source-id: 02b7555be
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.strictClass_convertingNullableToNonnullIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [Method `strictClass_convertingNullableToNonnullIsBad()` may return null but it is not annotated with `@Nullable`. (Origin: call to getNullable() at line 97)]
[nullsafe] Don't render type origin in trivial cases Summary: 1. We don't want to teach the users to ignore noise origin because sometimes we are going to render something useful for them. 2. It just looks not cool. Reviewed By: artempyanykh Differential Revision: D18527694 fbshipit-source-id: 0ea248122
5 years ago
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.strictClass_dereferenceNullableFieldIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`__new(...).nullable` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.strictClass_dereferenceNullableMethodIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`__new(...).getNullable()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.strictClass_dereferenceNullableStaticMethodIsBad():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`staticNullable()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictModeForThirdParty.java, codetoanalyze.java.nullsafe_default.StrictModeForThirdParty.dereferenceSpecifiedAsNullableIsBAD():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`StrictModeForThirdParty.obj.returnSpecifiedAsNullable()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictModeForThirdParty.java, codetoanalyze.java.nullsafe_default.StrictModeForThirdParty.dereferenceUnspecifiedIsBAD():void, 1, ERADICATE_NULLABLE_DEREFERENCE, no_bucket, WARNING, [`StrictModeForThirdParty.obj.returnUnspecified()` is nullable and is not locally checked for null when calling `toString()`.]
codetoanalyze/java/nullsafe-default/StrictModeForThirdParty.java, codetoanalyze.java.nullsafe_default.StrictModeForThirdParty.passingNullableParamToUnspecifiedIsBAD():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ThirdPartyTestClass.paramUnspecified(...)` needs a non-null value in parameter 1 but argument `getNullable()` can be null.]
codetoanalyze/java/nullsafe-default/StrictModeForThirdParty.java, codetoanalyze.java.nullsafe_default.StrictModeForThirdParty.passingNullableToParamSpecifiedAsNonnullIsBAD():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ThirdPartyTestClass.secondParamSpecifiedAsNonnull(...)` needs a non-null value in parameter 2 but argument `getNullable()` can be null.]
[nullsafe] 3rd party annotations from the repo are respected in nullsafe Summary: Follow ups will include error messaging that makes the choice clear Reviewed By: artempyanykh Differential Revision: D18347664 fbshipit-source-id: b6f005726
5 years ago
codetoanalyze/java/nullsafe-default/third-party-test-code/some/test/pckg/ThirdPartyTestClass.java, some.test.pckg.ThirdPartyTestClass.returnSpecifiedAsNullable():java.lang.String, 0, ERADICATE_RETURN_OVER_ANNOTATED, no_bucket, WARNING, [Method `returnSpecifiedAsNullable()` is annotated with `@Nullable` but never returns null.]