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

243 lines
84 KiB
Raw Normal View History Unescape

[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
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 `notInitializedNormalIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
[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] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
5 years ago
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife.assignNullToNormalIsBAD():void, 1, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [`normal` is declared non-nullable but is assigned a nullable: 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, [`convertingToNotNullableForNullableIsBAD()`: return type is declared non-nullable but the method returns a nullable value: field 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()`.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
5 years ago
codetoanalyze/java/nullsafe-default/ButterKnife.java, codetoanalyze.java.nullsafe_default.ButterKnife.passingToNullableForNullableIsBAD():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ButterKnife.f(...)`: parameter #1(`nonNullable`) is declared non-nullable but the argument `ButterKnife.nullable` is 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/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] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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()`: 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()`: 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()`: 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] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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()`: method parameter s]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`notAnnotatingReturnWhenThereAreNoPropagatesNullableIsBAD(...)`: return type is declared non-nullable but the method returns a nullable value: null constant at line 213.]
[nullsafe] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
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 `stillBad` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `bad` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `shouldBeGood_FIXME` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
[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`]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`bad` is declared non-nullable but is assigned a nullable: field nullable at line 182.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
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 `bad` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `o1` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `o` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `o1` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `f3` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `f5` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `f2` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `suppressWrongLintIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `nonNullIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `notNullIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `nonnullIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.FieldNotInitialized$Suppression.testNullifyFields():void, 3, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [`nonnullIsBAD` is declared non-nullable but is assigned a nullable: 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, [`nonNullIsBAD` is declared non-nullable but is assigned a nullable: 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, [`injectIsOK` is declared non-nullable but is assigned a nullable: 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, [`suppressAnnotationIsOK` is declared non-nullable but is assigned a nullable: 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, [`suppressLintIsOK` is declared non-nullable but is assigned a nullable: null constant at line 63.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
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 `bad` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.<init>(), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `dontInitAtAllIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.<init>(), 0, ERADICATE_FIELD_NOT_INITIALIZED, no_bucket, WARNING, [Field `initInAnyOtherMethodIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
[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.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.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotInitialized.java, codetoanalyze.java.nullsafe_default.TestInitializerAnnotation.set4(java.lang.String):void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [`initByNullableInInitializedMethodIsBAD` is declared non-nullable but is assigned a nullable: method parameter value.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
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 `initInUnknownMethodIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
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 `initInUnknownMethodIsBAD` is declared non-nullable, so it should be initialized in the constructor or in an `@Initializer` method]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.CanAssignNullInCleanupMethods.assignNullInAnyOtherMethodIsBAD():void, 1, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [`someObject` is declared non-nullable but is assigned a nullable: 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] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
5 years ago
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.<init>(), 4, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [`initializeNonNullableWithNullIsBAD` is declared non-nullable but is assigned a nullable: 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] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`notNullable` is declared non-nullable but is assigned a nullable: null constant at line 65.]
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.setNullableToNotNullableIsBAD(java.lang.String):void, 2, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [`notNullable` is declared non-nullable but is assigned a nullable: method parameter s.]
codetoanalyze/java/nullsafe-default/FieldNotNullable.java, codetoanalyze.java.nullsafe_default.FieldNotNullable.setNullableToNotNullableIsBAD(java.lang.String):void, 3, ERADICATE_FIELD_NOT_NULLABLE, no_bucket, WARNING, [`notNullable` is declared non-nullable but is assigned a nullable: 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] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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()`: call to AtomicReference.get() at line 35 (nullable according to nullsafe internal models)]
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()`: call to PhantomReference.get() at line 27 (nullable according to nullsafe internal models)]
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()`: call to Reference.get() at line 19 (nullable according to nullsafe internal models)]
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()`: call to SoftReference.get() at line 31 (nullable according to nullsafe internal models)]
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()`: call to Reference.get() at line 23 (nullable according to nullsafe internal models)]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: call to Map.get(...) at line 137 (nullable according to nullsafe internal models).]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument `nullableValue` is nullable.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: call to Map.get(...) at line 98 (nullable according to nullsafe internal models).]
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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: call to Map.get(...) at line 79 (nullable according to nullsafe internal models).]
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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: call to Map.get(...) at line 73 (nullable according to nullsafe internal models).]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `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(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: null constant at line 114.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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()`: call to ImmutableMap.get(...) at line 59 (nullable according to nullsafe internal models)]
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()`: call to Map.get(...) at line 44 (nullable according to nullsafe internal models)]
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()`: call to Map.get(...) at line 29 (nullable according to nullsafe internal models)]
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()`: call to Map.get(...) at line 24 (nullable according to nullsafe internal models)]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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, [`dontAssignNull` is declared non-nullable but is assigned a nullable: 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] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
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()`: field 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()`: field 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()`: field 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()`: field 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()`: field 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] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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()`.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
5 years ago
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `intent` is nullable.]
[nullsafe] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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] Render origin in a more light weight way Summary: It make the message bit less heavy, and also it is kind of obvious that it is origin. In follow up diffs we will change the text so it is hopefully even more obvious. Reviewed By: artempyanykh Differential Revision: D18527695 fbshipit-source-id: a305d547b
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()`: 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()`: 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()`: call to getNullable() at line 354]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
5 years ago
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()`: call to Map.get(...) at line 260 (nullable according to nullsafe internal models)]
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()`: call to HashMap.get(...) at line 261 (nullable according to nullsafe internal models)]
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()`: call to ConcurrentHashMap.get(...) at line 262 (nullable according to nullsafe internal models)]
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()`: call to Map.remove(...) at line 267 (nullable according to nullsafe internal models)]
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()`: call to HashMap.remove(...) at line 268 (nullable according to nullsafe internal models)]
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()`: call to ConcurrentHashMap.remove(...) at line 269 (nullable according to nullsafe internal models)]
[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] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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()`: call to Path.getParent() at line 360 (nullable according to nullsafe internal models)]
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()`: call to System.getProperty(...) at line 235 (nullable according to nullsafe internal models)]
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()`: call to System.getenv(...) at line 240 (nullable according to nullsafe internal models)]
[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(...)`.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
5 years ago
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(...)`: parameter #2(`s`) is declared non-nullable but the argument is `null`.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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(...)`: parameter #1(`s`) is declared non-nullable but the argument `s` is nullable: null constant at line 39.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
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(...)`: parameter #1(`s`) is declared non-nullable but the argument `s` is nullable.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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(...)`: parameter #1(`object`) is declared non-nullable but the argument `object` is nullable: 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(...)`: parameter #1(`object`) is declared non-nullable but the argument `formal parameter object` is nullable: null constant at line 112.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullIterable` is nullable: 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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullIterator` is nullable: 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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullCollection` is nullable: null constant at line 133.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.of(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.of(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListOfnotNullArguments():void, 7, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.of(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListSortedCopyOfNotNullArguments():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.sortedCopyOf(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableListSortedCopyOfNotNullArguments():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableList.sortedCopyOf(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullIterable` is nullable: 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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullMap` is nullable: null constant at line 178.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapOfnotNullArguments():void, 4, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.of(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapOfnotNullArguments():void, 6, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.of(...)`: parameter #4 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableMapOfnotNullArguments():void, 6, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableMap.of(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullIterable` is nullable: 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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullIterator` is nullable: 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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `nullCollection` is nullable: null constant at line 159.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 5, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 7, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 8, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)`: parameter #4 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testImmutableSetOfnotNullArguments():void, 8, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ImmutableSet.of(...)`: parameter #2 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `ns` is nullable: 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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument `ns` is nullable: null constant at line 185.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `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(...)`: parameter #1 is declared non-nullable (according to nullsafe internal models) but the argument is `null`.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
5 years ago
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testThreeParameters():void, 2, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.threeParameters(...)`: parameter #1(`s1`) is declared non-nullable but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testThreeParameters():void, 3, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.threeParameters(...)`: parameter #2(`s2`) is declared non-nullable but the argument is `null`.]
codetoanalyze/java/nullsafe-default/ParameterNotNullable.java, codetoanalyze.java.nullsafe_default.ParameterNotNullable.testThreeParameters():void, 4, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ParameterNotNullable.threeParameters(...)`: parameter #3(`s3`) is declared non-nullable but the argument is `null`.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`test(...)`: return type is declared non-nullable but the method returns a nullable value: field 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] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`getResourceNullable(...)`: return type is declared non-nullable but the method returns a nullable value: call to Class.getResource(...) at line 177 (nullable according to nullsafe internal models).]
[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.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
5 years ago
codetoanalyze/java/nullsafe-default/ReturnNotNullable.java, codetoanalyze.java.nullsafe_default.ReturnNotNullable.nullToNonnullIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [`nullToNonnullIsBad()`: return type is declared non-nullable but the method returns a nullable value: 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, [`nullToNotAnnotatedIsBad()`: return type is declared non-nullable but the method returns a nullable value: 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, [`nullableToNonnullIsBad(...)`: return type is declared non-nullable but the method returns a nullable value: 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, [`nullableToNotAnnotatedIsBad(...)`: return type is declared non-nullable but the method returns a nullable value: method parameter s.]
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, [`return_null_in_catch()`: return type is declared non-nullable but the method returns a nullable value: 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, [`return_null_in_catch_after_throw()`: return type is declared non-nullable but the method returns a nullable value: 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, [`tryWithResourcesReturnNullable(...)`: return type is declared non-nullable but the method returns a nullable value: call to nullToNullableIsOK() at line 142.]
codetoanalyze/java/nullsafe-default/StrictMode.java, codetoanalyze.java.nullsafe_default.Strict.nonStrictClass_convertingNonnullToNonnullIsBad():java.lang.String, 0, ERADICATE_RETURN_NOT_NULLABLE, no_bucket, WARNING, [`nonStrictClass_convertingNonnullToNonnullIsBad()`: return type is declared non-nullable but the method returns a nullable value: 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] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`nonStrictClass_convertingNullableToNonnullIsBad()`: return type is declared non-nullable but the method returns a nullable value: 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] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`sameClass_convertingNullableToNonnullIsBad()`: return type is declared non-nullable but the method returns a nullable value: 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] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
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, [`strictClass_convertingNullableToNonnullIsBad()`: return type is declared non-nullable but the method returns a nullable value: 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()`.]
[nullsafe] Always specify if the nullability comes from internal models or third party Summary: 1/ We now support messaging for third-party: show file name and line number 2/ We did not show information about internal models in case of param calls 3/ Small change: we don't specify "modelTables.ml" anymore: no need to expose implementation details Reviewed By: artempyanykh Differential Revision: D18569790 fbshipit-source-id: 28586c8ff
5 years ago
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()`: call to ThirdPartyTestClass.returnSpecifiedAsNullable() at line 45 (declared nullable in nullsafe-default/third-party-signatures/some.test.pckg.sig at line 2)]
[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/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()`.]
[nullsafe] Changes in wording of error messages: unified and more clear language Summary: Whole bunch of changes aimed to make error messages more clear and concise. 1/ Wording and language is unified. We make errors sound more like a type system violations, rather than linter reccomendations. Particularly, we refrain from saying things like "may be null" - this is a linter-style statement that may provoke discussions (what if the developer knows it can not be null in this particular case). Instead, we refer to declared nullability and nullability of actual values. This way, it is more clear that this is not a heuristic, this is how rules of a type-system work. 2/ Additionally, we drop things like field class in places when the context should be clear by who looks at the error. We expect the user sees the code and the error caption. So e.g. we don't repeat the word "field" twice. 3/ In cases when we are able to retrieve formal param name, we include it for usability. 4/ For Field not initialized error, we refer to Initializer methods: this is a non-obvious but important nullsafe feature. Reviewed By: artempyanykh Differential Revision: D18569762 fbshipit-source-id: 9221d7102
5 years ago
codetoanalyze/java/nullsafe-default/StrictModeForThirdParty.java, codetoanalyze.java.nullsafe_default.StrictModeForThirdParty.passingNullableParamToUnspecifiedIsBAD():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [`ThirdPartyTestClass.paramUnspecified(...)`: parameter #1(`param`) is declared non-nullable but the argument `getNullable()` is nullable.]
[nullsafe] Special error messaging for case when unmodelled third-party signature is called Summary: Two goals: 1. Be less assertive when speaking about third party code (it might be written with different conventions). 2. Point to third party signatures folder so the users know how to proceed Reviewed By: artempyanykh Differential Revision: D18571514 fbshipit-source-id: 854d6e746
5 years ago
codetoanalyze/java/nullsafe-default/StrictModeForThirdParty.java, codetoanalyze.java.nullsafe_default.StrictModeForThirdParty.passingNullableToParamSpecifiedAsNonnullIsBAD():void, 1, ERADICATE_PARAMETER_NOT_NULLABLE, no_bucket, WARNING, [Third-party `ThirdPartyTestClass.secondParamSpecifiedAsNonnull(...)` is missing a signature that would allow passing a nullable to param #2(`specifiedAsNonnull`). Actual argument `getNullable()` is nullable. Consider adding the correct signature of `ThirdPartyTestClass.secondParamSpecifiedAsNonnull(...)` to nullsafe-default/third-party-signatures/some.test.pckg.sig.]
[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.]