In case the referred type is actually an enum that is not found in
dependencies due to a configuration problem, this usage could be valid.
So we can avoid reporting an error here, to reduce the number of
diagnostics.
Also do not report "default value of annotation parameter must be a
compile-time constant" in the same case for the same reason
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
- Introduce new language feature 'ReadDeserializedContracts', which
allows to deserialize contracts from metadata.
- Introduce new language feature 'AllowContractsForCustomFunctions',
which allows reading contracts from sources.
- Use new features instead of combination 'CallsInPlaceEffect ||
ReturnsEffect'
- Rename 'CallsInPlaceEffect' -> 'UseCallsInPlaceEffect',
'ReturnsEffect' -> 'UseReturnsEffect'. As names suggest, they control
if it is allowed to use corresponding effect in analysis.
We have to introduce separate 'ReadDeserializedContracts' to enable
contracts only in some modules of the project, because libraries are
read with project-wide settings (see KT-20692).
Consider following case:
fun foo(): Unit = run { "hello" }
Previously, NI would analyze lambda body without expected type, because
it is a type variable 'R' from 'run', which hasn't been fixed yet. This
leads to treating "hello" as lambda-return argument and adding bogus
'String' constraint on 'R', and, consequently, type mismatch.
Now, we peek into current constraint system and check if return-type of
lambda is type variable with upper-Unit constraint (which is exactly
condition for its body to be Unit-coerced). If so, then we provide
expected Unit-type for body explicitly, and the rest will be done
automatically (in particular, in aforementioned example "hello" wouldn't
be treated as lambda return argument).
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
*.kjsm and other files might be received when FileCollection is
used in Gradle as a dependency.
Example: `testCompile project(":$coroutines_core").sourceSets.test.output`
(a popular-ish solution to introduce dependencies between tests)
It's implemented through Jsr305State while it's not related
to jsr-305 becasue currently it's the most convenient way
to introduce the flag.
Probably, it's worth renaming Jsr305State to something more abstract
like NullabilityAnnotationsConfiguration
#KT-21982 Fixed
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_.
Otherwise accessors for backing fields (as in '{ field }') clash with
accessors for properties (as in '{ prop }').
#KT-21258 Fixed Target versions 1.2.30
Ilya Chernikov