Right now, during the process of inlining, the compiler erases types.
Because of that, we can end up with some random type
(for example, `Any`) where the concrete type was
expected (for example, `Int`). Compiler must insert a cast in the
required places.
#KT-66017 Fixed
Previously, it was failing at line
(resolvedReceiver?.toReference(session) as? FirNamedReferenceWithCandidate)?.candidate?.updateSourcesOfReceivers()
But this line was mostly incorrect because in case of `a.b()` call,
which is resolved to `a.b.invoke()`, `resolvedReceiver` is pointing to
`a` instead of obviously expected `a.b`.
The fix with using `candidate.callInfo.explicitReceiver` doesn't help
either because the candidate of that receiver is always completed at
that stage (so no Candidate there).
The only case when the candidate was still there is PCLA because
in that case we explicitly don't fully complete even receiver
expressions.
(see docs/fir/pcla.md)
The idea of the fix is moving the call of `updateSourcesOfReceivers`
for invoke property receiver to the place just before the candidate
is being converted to the resolved reference
(i.e., the candidate is being lost)
^KT-66148 Fixed
This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
If there is an expression receiver, we should process constructors only
of inner classes. Constructors of nested classes can be called only
on classifier
^KT-65333 Fixed
This is an addition to d4278250e6. Apparently we still need to produce
a new fake override for each inherited static member, because otherwise
we would try to determine the most specific return type, maximum
visibility, etc, all of which makes no sense for static members.
#KT-66152 Fixed
This diagnostic is reported in rare situations when
StubTypeForBuilderInference is kept as a parameter type
of for loop or lambda. Before this commit, we had in K1
"Could not load module <error module>" from IrLinker instead.
Related to: KT-52757, KT-53109, KT-63841, KT-64066
#KT-53478 Fixed
Usually we create synthetic property in java class if there is a property
from the base kotlin class and getter/setter with a corresponding name
in the declared scope or one of supertype scopes. But there is a case,
where the same supertype contains both property and getter:
```
// FILE: Base.kt
open class Base {
open val b = "O"
@JvmName("getBJava")
fun getB() : String = "K"
}
// FILE: Derived.java
public class Derived extends Base {}
```
In this case we shouldn't create synthetic property, because `getB()`
function is invisible for `Derived` class
^KT-66020 Fixed
The previous one was incorrect for K1 since parent of top-level function
is `IrClass`, not `IrPackageFragment`.
The change is non-functional, K1 still worked correctly, but had to do
some extra work when inlining `emptyArray` calls and produces less
performant bytecode.
A class can inherit two declarations that are compatible from the
overridability standpoint and are therefore combined to a non-trivial
intersection.
At the same time, the class can declare a member declaration that
only overrides one of the intersection's members.
In this case, we break up the intersection and only add the overridden
parts to the declared member's direct overridden list.
If the class doesn't override the intersection, it exists as
intersection override, like before.
#KT-65487 Fixed
Previously we forced computation only for java and precompiled classes,
assuming, that binary class can not extend source class, but it's not
true in two cases:
1. Classpath substitution: class with same name declared in library and
the source (more rare case)
2. Metadata compilation: depends-on dependcies are passed in binary
format, so `expect class` may be a binary one and corresponding
`actual class` may be a source. So if some class in `common` module
extend this expect class, actual class will be substituted instead of it
^KT-65669 Fixed
This is needed because in case a static member is inherited via a Kotlin
class (class C in the newly added test), its origin becomes
FAKE_OVERRIDE which is technically not Java anymore. After this change,
we'll build fake overrides for static members from superclasses
regardless of whether they come from Java or Kotlin.
Also, move the previous logic of
isOverridableFunction/isOverridableProperty to the only call site at
IdSignatureFactory.
#KT-65589 Fixed
Before this commit, fir f/o builder was inconsistently
disabled in some places, while it should work only for lazy declarations
Attempt to use it for non-lazy declarations, without maintaining
invariant, that it would also be used for super classes
led to unpredictable results.
This commit introduces opt-in, and marks all related API to three types
* Propagate error to user
* Fine to use, as it's checked if ir f/o builder is enabled
* Fine to use, as it is definitely a lazy class.
Several cases of missing checks was fixed.
^KT-65707
Java annotation interface fields are constant declarations that can
have any Java type and are not restricted in the same way that
method return types are for annotation interfaces.
#KT-65482 Fixed
We have two sources of truth in Fir2Ir - declaration storages,
which maps fir to ir symbols and symbolTable which maps
IdSignature to ir symbol.
The long-term goal is to have only one - declaration storages. This
commit goes to this goal by removing all symbolTable usages that are
straightforward to remove, i.e., all except:
1. classes as there is some code, that uses signature inside ClassSymbol
2. functions/properties as sometimes declaration storage fails to match
symbols correctly (i.e. for generated data class members)
3. type parameters, as we need to remove functions first.
As a side effect, it fixes some of the signature clash cases on valid
code, as we no longer rely on signature uniqueness, except cases
mentioned above.
^KT-65274 Fixed
^KT-64990
Otherwise it leads to the following problem in the newly added test.
Suppose that we have a fake override `remove(Int)` inherited from
LinkedList _without_ EnhancedNullability on its parameter type. By
normal Kotlin rules, this method should override the method from
KotlinInterface. However, on JVM we have another overridability check in
IrJavaIncompatibilityRulesOverridabilityCondition which ensures that
"JVM primitivity" of parameter types is the same for the base and the
overridden method.
So the fake override `remove(Int)` from LinkedList is determined to be
override-incompatible with `remove(Int)` from KotlinInterface. But when
we try to create symbols for all fake overrides in the class, we get a
clash because there are two fake overrides with exactly the same
IdSignature, neither of which overrides the other.
If we keep the EnhancedNullability annotation on the parameter, it
starts working because the logic of computing signature in
JvmIrMangler.JvmIrManglerComputer.mangleTypePlatformSpecific adds an
"{EnhancedNullability}" mark to the IdSignature of a fake override from
LinkedList.
#KT-65499 Fixed
Ivan Kylchik