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
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
to make their UserData survive for longer, because otherwise a new LightClass with empty UserData comes to Spring every time, but Spring stores a lot of important things in UserData
Remove unnecessary non-null parameter checks inside static delegate methods
created for @JvmStatic companion object methods. Allows function generation
strategy decide if such checks need to be injected.
#KT-7188 Fixed
If the loop end value is a compile-time constant (best we can do now),
and it is safe to iterate over a given range using "naive" for loop
(using '<=' or '>=' in loop condition),
generate such loops for Longs and Chars as well Ints (Bytes, Shorts).
Mikhael Bogdanov