IrSetField was transformed to its value to preserve side effects
This transformation produced invalid IR in cases where
IrSetField used in Unit-returning expression context.
This commit fixes it by producing Unit-typed expression
^KT-59084 Fixed
^KT-59665 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
It's better to have this logic in common place
(AbstractExpectActualCompatibilityChecker) to avoid missing compilation
errors in the future
This commit fixes:
1. Missing compilation error for actual function with default arguments
for 'actual typealias' KT-59665
2. Missing compilation error for actual function with default arguments
for actual fake-override KT-59665
Alternative solution for KT-59665 is to create a special checker.
"incompatibility" vs "special checker":
Arguments for common incompatibility:
- What if we had a rule that expect and actual default params must
match? If so then it certainly would be an incompatibility.
- Technically, we do the matching of expect and actual params (because
we allow default params in common ancestors of expect and actual
declarations).
- It's hard to check that the actual definition doesn't use default
params because `ExpectedActualResolver.findActualForExpected` filters
out fake-overrides and doesn't return them. It's not clear logic for
me, that I'm afraid to touch.
implicitActualFakeOverride_AbstractMap.kt test breaks if you drop this
weird logic
- WEAK incompatibilities can be considered as "checkers". So it doesn't
matter how it's implemented, as a "incompatibility" or a "checker"
Arguments against common incompatibility:
- Although we match expect and actual declarations to allow default
params in common ancestors of expect and actual declarations, it's
still can be considered that we check that the actual declaration
doesn't have default params. And it doesn't feel right that we check
correctness of the actual declaration in expect-actual matcher.
- ~~It may change the rules of expect actual matching~~ (It's not true,
because ActualFunctionWithDefaultParameters is declared as WEAK
incompatibility)
Currently, property `hasSourceAnnotationsErased` returns the opposite
to what is stated in name. Invert it both in implementation and on
call site.
^KT-58551
There's also SYNTHETIC_OFFSET, which is used for example for
declarations generated by interface delegation, for which
`sourceElement` threw exception. It didn't lead to any user-visible
error AFAIK, I've encountered this problem while working on 5f2ff06296.
Do not try to find PSI element, but always use the IR element offsets
instead. This greatly simplifies test data because we don't need to have
custom PSI- and LT- based diagnostic ranges in every test, and K1/K2
behavior also is mostly the same.
The exact offset ranges are not as important for backend diagnostics, so
it's better to have K2+PSI and K2+LT behaving the same.
By ignoring type parameters. Since type parameters in annotations are a
very limited feature, their sole use is to be able to specify them as
KClass argument: annotation class Foo<T: Any>(val bar: KClass<T>).
Since we can encounter type param only as a KClass type argument (and
never as a property type), simple approach of ignoring them works fine.
In that case, since we simply copy property types to synthetic
implementation class, its properties in IR start look like this:
annotation class FooImpl(override val bar: KClass<T of Foo>). This IR
seems to be not completely correct, since FooImpl.bar type contains T of
Foo param, which is out of its scope. However, so far I didn't
encounter any problems with this during testing and after MR discussion
this approach has been considered possible.
#KT-59558 Fixed
#KT-59036 Fixed
Many errors are reported in stdlib with these annotations
(SinceKotlin, Deprecated, so on).
But having them only on expect is a valid case. E.g. SinceKotlin added
if some old platform-specific API becomes commonized.
^KT-58551
This implementation only checks annotations set on expect/actual
declarations and requires further refinement (e.g. checking of other
annotation targets, class scopes within typealiases).
^KT-58551
This will help in some lowerings which need to change the callee of a
call. Instead of creating a new call and copying everything (type
arguments, value arguments, receivers, annotations, attributes, ...),
it's easier to modify the `symbol`. In a way, this is a continuation of
22b4b29292.
In this commit we have a lot of change in test data. This was caused
by the way where we evaluate constants. We split constant evaluation
into two distinct parts: only necessary evaluations for `fir2ir`
(like const val and annotations) and optimizations for lowering.
Now we don't do all constant evaluation on `fir2ir`, but IR
dump is executed after this phase, so test data changed.
#KT-58923
In terms of MPP there are no such thing as `expect constructor` for enums,
but they are physically exist in FIR and IR, so we need a switch which
skips matching for them
FE 1.0 implementation did not touch to avoid any hidden changes
Ivan Kochurkin