They are hardcoded to avoid having dependency from android.jar on
our annotations' jar with UnderMigration.
Even while it could be a compile-only dependency we need to make sure
that annotated types are read properly without RecentlyNonNull/RecentlyNullable
in the classpath
#KT-24278 Fixed
Fix TypeUtils.makeNullableAsSpecified for SimpleTypeWithEnhancement and
FlexibleTypeWithEnhancement: change nullability of enhancement too. This
fixes several false-positive warnings, like in KT-20855 and KT-20466.
Note that it removes warning in some cases (see testdata change for
uselessElvisRightIsNull.kt). However, this removes warning about
*unnecessary* elvis, i.e. this fixed introduces weak false-negatives, which
is acceptable for the moment.
#KT-20855 Fixed Target versions 1.2.30
#KT-20466 Fixed Target versions 1.2.30
#KT-21238 Fixed Target versions 1.2.30
We are migrating Guava to use these annotations rather than jsr305's
@Nullable. We can't use the Checker Framework's _@Nullable_ yet because
we promise compatibility with Java 7, which doesn't support type
annotations. This is related to but distinct from
https://youtrack.jetbrains.com/issue/KT-21408, which is about a
different jsr305 annotation we use, @ParametersAreNonnullByDefault.
I've also updated some docs to mention Kotlin's existing support for the
Checker Framework _@NonNull_.
This NPE was introduced in ce41b5745a
Prior to the latter change there was a synthetic PSI element for each
equals-related call, thus callOperationNode was not null here.
== are intentionally treated as safe calls, but for nullability checker
it's not relevant, it only should report warnings on real safe-calls
Before this chanhe, these annotations are simply ignored, but they should
preserve flexibility in case of enhanced nullability obtained from
enclosing default qualifier
#KT-20158 Fixed
The problem was that `resolveTypeQualifierAnnotation` actually doesn't
guarantee that `typeQualifierAnnotation` is javax.annotation.NonNull
with argument
It could be just any type qualifier (see the test)
For sake of working without jsr305.jar in the classpath `resolveTypeQualifierAnnotation`
may return javax.annotation.CheckForNull (although the latter is nickname itself)
#KT-19985 Fixed
It was only used for type-related nullability/mutability
annotations and it was necessary to remove them
in the descriptor renderer (duplicating their fqnames there).
At the same time they're only needed for types enhancement
where they can be simply restored from type owners' descriptors
The testData changes are more or less correct: this kind of annotations
is bound both to types themselves and their use because of their targets
- tests and declarations for checkerframework has been moved,
because they only Java 8 targeted
- tests for eclipse annotations has been just copied,
because there are two jars: one for Java 8 and other for earlier versions
Java nullability annotations may generate types that currently are not denotable in Kotlin:
class Java {
void <F> foo(@NotNull F f) {}
}
Type of given value parameter should be not nullable under any substitution:
String/String?/String! because of annotation contract.
NB: Currently there is no full analogues for such types in pure kotlin
Mikhael Bogdanov