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
Roman Efremov