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 reverts commit 6271f5cbe5.
The original commit 15094eb03a was reverted because it caused a problem
during bootstrap. That problem is fixed in a subsequent commit.
In more details, we use either platform override checker (if we came
from platform) or the combined intersection scope override checker
at this place. Also this commit fixes various places around
JavaOverrideChecker, allowing to apply it in intersection override
checker properly:
- don't consider return types in this place
- apply JavaOverrideChecker if at least one candidate is from Java
- compare type primitivity closer to K1 logic
#KT-62554 Fixed
Partially fixes KT-63242
This origin was set somewhat arbitrarily.
It actually only makes sense for `IrCall`s to property getters.
There were no places in lowerings that checked `IrGetField` expressions
for this origin value.
^KT-62500 Fixed
This commit gets rid of the redundant typeApproximatorConfiguration
in Fir2IrTypeConverter and uses the type approximator for captured
types instead of the manual approximation used before.
This fixes the nullability of approximated captured types, which fixes
a runtime error in WASM.
This also brings K2 IR closer to K1 IR in one test.
#KT-64261 Fixed
After a generation of fake overrides some code may still to refer old
symbols from declaration storage (like computation of overridden
symbols for lazy functions), so we need to remap those symbols using
information from IR f/o generator
This commit handles situations when some annotation in deserialized code
has an empty array literal argument [] or even non-empty [something].
Before this commit, we tried to guess a type of this array by "resolving"
the relevant annotation class and looking into the corresponding
parameter. Sometimes it can work, but also it can provoke recursive
resolve e.g. when the annotation class is a nested class in the same scope.
In this commit we changed the behavior in the following way:
- first, for non-empty array literals in deserialized code we just
take the array type from the corresponding array literal element
- second, for empty array literals we no more try to "guess" anything.
Instead we approximate array type as Array<Any>, and later at FIR2IR
stage we use the corresponding parameter type instead. At FIR2IR stage,
everything is already resolved and problems with recursions are no more
possible.
#KT-62598 Fixed
Before this commit, we first tried to guess a type of array literal
in deserialized annotation (it's a strange heuristics which can
lead to SOE and maybe not needed at all, see KT-62598, KT-62929),
and then, if unsuccessful, took the type from the first literal element,
if any. Since the second heuristic is much more clear, safe, and
understandable, in this commit they were swapped.
This commit does not fix KT-62598 in general case,
but decreases a set of cases when it can occur to
empty array literals only.
See the commented line at the end of the added test.
For reasoning refer to the message of the previous commit
It is the same as for `getIrFunctionSymbol`
There is one failing test here, caused by KT-61941
The issue was here before this commit, but it was hidden
`FakeOverrideBuilder.provideFakeOverrides` recursively changes overrides
for all superclasses in the hierarchy, including lazy IR, which is a lot
of extra work.
Also it leads to some tests failing in the IR fake override builder mode
because it changes correct fake overrides of Java classes to incorrect
ones. Those tests are unmuted but it doesn't mean they are fixed -- most
likely we'll generate fake overrides via IR for lazy IR too, at which
point they'll start to fail again.
Dmitriy Novozhilov