Now all tests with `Fir` in name are named accordingly to parser which
is used in them -- `FirPsi` or `FirLightTree`. This is needed to keep
consistency between different types of tests, because there is no
single default in parser mode between different scenarios of using FIR
These declarations should not be visible to users (and therefore are not added to FIR),
but plugin itself can reference them in already compiled serializable classes,
and therefore they should be available in metadata:
- synthetic deserialization constructor
- static write$Self function
See also:
^KT-55885
If enum class from dependencies is used, which was compiled by a new version of the plugin, which uses a factory and does not create a nested `$serializer` class, then an `SERIALIZER_NOT_FOUND` diagnostic error is thrown for such an enumeration.
This happens if the old serialization runtime is used for the current project - in this case, the serializer is taken from the nested class `$serializer`. Since it is missing, the diagnostics does not work correctly.
It is acceptable for enumerations to ignore this error, because we know that enumerations are always serializable.
Merge-request: KT-MR-8818
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
- Add IrPluginContext to JvmBackendContext, so plugin intrinsics can
reference external functions properly.
- Do not use module.findClassAcrossModuleDependencies as Descriptor API does not work for FIR.
- Add asm listing tests in serialization plugin for K2
- Remove Delegated.kt asm listing test as we have similar test in boxIr group.
#KT-56553 Fixed
Because SerializationJvmIrIntrinsicSupport does not instantiate annotations yet,
this info could be lost. As a workaround, it is possible to call Companion.serializer()
functions instead of direct serializer instantiation, as they are plugin-generated
and correctly handle annotations.
Note that for some cases (enums & interfaces) this WA is not enough, so additional work
is needed later.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2179
This change affects nothing, because @Serializable is checked during
COMPILER_REQUIRED_ANNOTATIONS when typealiases
are not yet resolved, but in case we change something
in the Future and want to support it, we'd have one less problem
`FirDeclarationGenerationExtension.generateClassLikeDeclaration` was split
into two functions: one for generating top level classes, and one for
nested classes. Such change reduces verbosity and error-proness of
this extension and also allows to smoothly run plugins on local classes
^KT-55248 Fixed
as it may have no primary constructor (only actual class has it).
Refactor & rename Fir2IrGeneratorUtils.kt as having 'Fir' in stacktrace
when actual K2 compiler is not used is very confusing.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2134
#KT-55683 Fixed
Name check was forgotten during refactoring, so any user function with
matching signature could be overwritten by the plugin, while correct
function would not have body.
#KT-55682 Fixed
of the class used in @UseSerializers: Use methods to receive
full list of supertypes.
K1 supertypes() call returned all supertypes, while
IrClass.supertypes and FirClassSymbol.resolvedSuperTypes return only immediate ones.
This lead to a difference in behavior between K1 and K2, and regression
after plugin backend was rewritten from descriptors to IR.
#KT-55340 Fixed
as ISE is more appropriate exception for validation.
Improve SerializerClassLowering.runPluginSafe so precise IrClass
where plugin have failed can be reported for non-fatal errors.
#KT-55296 Fixed
write$Self in K1 is created only on JVM, so we need this check to avoid
creating IR function without original descriptor — it will lead to various
bugs in JS and Native, such as superclass properties missing from output
when super.writeSelf is not found in descriptor.
Fixes #KT-55180
Now annotations are resolved with following algorithm:
1. On COMPILER_REQUIRED_ANNOTATIONS we resolve all annotations
and store results if this is compiler annotation, plugin annotation,
or annotation with meta-annotation (meta annotations are checked
recursively with designated resolution if needed)
2. On TYPES stage we resolve all those annotations once again and if
some annotation changes resolution then we keep type from p.1 and
report error on this annotation, so user should disambiguate it
Ambiguity may occur because of nested annotations with same name as
plugin annotations:
```
annotation class SomeAnnotation // (1) plugin annotation
open class Base {
annotation class SomeAnnotation // (2)
}
class Derived : Base() {
@SomeAnnotation // <-----------------
class Inner
}
```
At COMPILER_REQUIRED_ANNOTATIONS annotation call will be resolved to (1)
because at this stage supertypes are not resolved yet, and we consider
only importing scopes. At the TYPES stage we will find correct
annotation from supertype
Now predicates are split into LookupPredicate and DeclarationPredicate
hierarchies. First one allows to perform global search for declarations
and second one allows to check if some declaration matches the predicate.
Predicates with meta annotations are excluded from LookupPredicates,
because it's impossible to create index of annotations with meta-annotations,
because they can be located inside binary dependencies (so to achieve
this we need to scan the whole classpath).
Also only one predicate with meta-annotations is left in DeclarationPredicate
hierarchy (AnnotatedWithMeta)
^KT-53874 Fixed
^KT-53590 Fixed
K2 plugin API has a limitation that meta annotations from plugin predicates
can't be used on nested annotations because their resolve process includes supertypes
resolve, that can be affected by the plugin itself. Therefore, @MetaSerializable
can't be applied to nested annotation classes in K2, which is reflected by
this diagnostic.
For old FE, diagnostic is lowered to WARNING with deprecation message.
Dmitriy Novozhilov