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
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).
Change generic signature of MutableMap.getValue, use 'out @Exact V' and `V1: V` types instead of single `in V`.
Fix affected IR generation tests.
#KT-18789 Fixed
This commit introduces proper handling of recursion in scopes, which
could occur when some of companion object supertypes are members of
that companion owner:
```
class Container {
open class Base
companion object : Base()
}
```
To resolve `Base`, we have to build member scope for `Container`.
In the member scope of `Container`, we see all classifiers from
companion and his supertypes
So, we have to resolve companion objects supertype, which happens to be
`Base` again - therefore, we encounter recursion here.
Previously, we created `ThrowingLexicalScope` for such recursive calls,
but didn't checked for loop explicitly, which lead to a wide variety of
bugs (see https://jetbrains.quip.com/dc5aABhZoaQY and KT-10532).
To report such cyclic declarations properly, we first change
`ThrowingLexicalScope` to `ErrorLexicalScope` -- the main difference is
that latter doesn't throws ISE when someone tries to resolve type in it,
allowing us to report error instead of crashing with exception.
Then, we add additional fake edge in supertypes graph (from
host-class to companion object) which allows us to piggyback on existing
supertypes loops detection mechanism, and report such cycles for user.
The issue here is that OI infers correct types for (k, v) destructing
declaration, while NI infers errors for them. That happens because NI
resolves iterator() on nullable 'm', but rightfully reports it as
unsuccessful, while OI somehow manages to resolve it to success (and
thus getting nice expected type, allowing destructing declaration to be
resolved in a proper types).
Previously, there was receiver of type Nothing, which could case result
of the call to be inferred to Nothing too. This could case bogus
UNREACHABLE_CODE diagnostics in cases like this:
```
fun <T> id(x: T) = x
fun test() {
id(unresolvedReference) // type of statement is 'Nothing'
// ... everything here is marked as unreachable ...
}
```
This commit changes type of receiver for such calls form Nothing to
ErrorType.
This commits introduces testdata changes, where NI behaviour strictly
improved, after several previous fixes.
For some tests, just WITH_NEW_INFERENCE directive was added. It
indicates, that some of previous commits first introduced error in that
test, and then some other commit fixed it (netting no overall testdata
change). It is preferrably to keep those annotations until we will
migrate to NI completely, to prevent unexpected regressions.
In Kotlin 1.3+, assignment to the for-in-array loop range variable in
the loop body doesn't affect loop execution (as if it was a loop on an
array iterator, or some other container).
#KT-21354 In Progress
#KT-21321 In Progress
According to KT-21354, this should be a warning in 1.2 and before, and
no warning (with changed semantics) in 1.3 and later.
NB there are some false positives in this check.
#KT-21354 In Progress
#KT-21321 In Progress
When the enum entry requires a specific class, its constructor should
invoke proper supertype constructor (from the corresponding enum class).
Corresponding resolved call should be passed from the front-end in
CONSTRUCTOR_RESOLVED_DELEGATION_CALL slice.
In case of enum entries without explicit supertype initializer, this
information was missing.
This behavior was used until 6a1b6d10d8, where the JDK has
unintentionally started to be added to the end of the list, breaking
code which depended on libraries which bundle something from the JDK
#KT-21299 Fixed
For-in-string loop can be generated using specialized 'length' and
'charAt' method calls, and with cached string length.
Note that update of the string variable in loop body doesn't affect
loop execution semantics.
#KT-21322 Fixed Target versions 1.2.20
If the range expression is not a local variable (which can be updated in
the loop body affecting loop behavior, see KT-21354), we can cache the
array length, thus turning a for-in-array loop into a simple optimizable
counter loop.
#KT-21321 In Progress
Denis Zharkov