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
At this point, `deepCopyWithVariables` is the same as
`deepCopyWithSymbols` except that the former doesn't call
`patchDeclarationParents`, which most likely produces incorrect IR in
some call sites.
- `CompilationException` should not strongly reference `IrFile`s and
other IR elements, which in turn reference FIR elements strongly. It
can lead to a memory leak in the IDE as the exception is held
statically in the IDE's `MessagePool`.
- I considered fixing this on the level of `KtCodeCompilationException`
from the Analysis API, but:
1. `KtCodeCompilationException` can wrap many kinds of exceptions.
Snapshotting the cause only for `CompilationException` (somewhere
down the cause chain) would be messy, as it'd require traversing
the cause chain and referencing `CompilationException` directly,
breaking API boundaries.
2. Keeping the same level of report quality while snapshotting a cause
is not trivial.
3. Exceptions in general should be as lean as possible, so it makes
sense to fix `CompilationException` itself.
^KT-65655 fixed
Substitution of type arguments to non-reified type parameters may lead
to accidental reification, which should not be done (see ^KT-60174 for
examples). So, we should erase them, except the few cases.
^KT-60174: Fixed
^KT-60175: Fixed
Replace every property with its getter and setter. This is needed
because later on, JVM backend assumes that all properties have been
lowered (by JvmPropertiesLowering) to this state.
#KT-64116 Fixed
IrStatementOriginImpl and IrDeclarationOriginImpl were made final
classes to simplify the creation of them (a delegate provider was
added) and to optimize performance when comparing the origins by type
and name
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
`AbstractExpectActualChecker` works on pairs obtain from
`AbstractExpectActualMatcher` and the last one always returns single
actual for single expect. That's why handling of multiple actuals
doesn't make sense
It became possible to drop it after KT-62590. Now, on a frontend, the
return type check is part of a common AbstractExpectActualChecker logic
Change in nestedAnnotationClassViaActualTypealias.fir.kt aligns the
behaviour with K1. KT-61964
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
Those two functions are copy-paste of each other. They diverged since
the time they were copy-pasted. This commit makes
FirExpectActualMatchingContextImpl.areCompatibleExpectActualTypes
up-to-date.
I didn't update ExpectActualUtilsKt.areCompatibleExpectActualTypes
because I will drop it in the next commit.
Change in `dynamicTypesEqualToAnything` doesn't change any logic (yet.
This change in logic will take effect in the next commit), because:
1. `dynamicTypesEqualToAnything` is only changed in
AbstractExpectActualChecker.getCallablesCheckingIncompatibility. But
AbstractExpectActualChecker.getCallablesCheckingIncompatibility doesn't
check return types on frontend (it only check return types on backend).
2. `dynamicTypesEqualToAnything` is ignored on IR backend
I have no idea what is the difference between `createTypeCheckerState()`
and `actualSession.typeContext`, but it aligns these copy-pasted
versions and makes the tests behave like in K1 (at least
'typeUsageWithUnresolvedReference' and 'kt57320' are affected)
This commit is mainly a preparation for the next commit.
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
- getCallablesStrongIncompatibility is unused (because it moved to the
"matcher" KT-62590)
- `checkClassScopesCompatibility` parameter is always `true` or unused
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
- Migrate ExpectActualCompatibility -> ExpectActualCheckingCompatibility
where the "checker" is expect
- Migrate ExpectActualCompatibility -> ExpectActualMatchingCompatibility
where the "matching" is expect
KT-62590 in progress. A lot of tests start to fail now. I will fix them
in next commits
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
Alexander Udalov