- `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
This is a minor optimization.
This commit is a step forward for KT-62590
Conceptually, `checkClassScopesCompatibility` belongs to the
"expect-actual checker". It doesn't belong to the "expect-actual
matcher".
- `checkClassScopesCompatibility` should be set to `true` when you want
to do the "checking"
- `checkClassScopesCompatibility` should be set to `false` when you want
to do the "matching"
`collectActualCallablesMatchingToSpecificExpect` only needs the
"matching"
No tests changed their behaviour
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
`stickyPostconditions` are such conditions that are checked
every time after applying when a new lowering finishes its execution.
Right now we are using them only in JVM, and this is a blocker
for adopting Native approach for lowering execution.
In Native we are using
`SimpleNamedCompilerPhase<in Context : LoggingContext, Input, Output>`
as the common super type for all lowerings. Here we have `Input` and
`Output` that can potentially be different and `stickyPostconditions`
don't have much sense in that case.
Sergej Jaskiewicz