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.
Do not use plugin origin for user-written classes that have @Serializer annotation for some reason. Plugin origin makes them synthetic which is incorrect because they're available in source code. Example of such class: @Serializer(JsonElement::class) class JsonElementSerializer
Merge-request: KT-MR-7627
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
- IR plugin does not use it anymore,
regular annotation instantiation feature is used
(insertion of IrConstructorCall(annotationCtorSymbol)).
- IR plugin still generates `SerialInfo$Impl` class to be compatible
with previously compiled code & libraries.
- Custom implementation over descriptors in IR plugin is removed;
plugin now delegates to the existing lowering with some tweaks.
- $Impl descriptor is removed from FE 1.0 because it is no longer needed
for IR plugin; it shouldn't be exposed to users so FIR doesn't need it either.
- Since language lowering is now used, it is possible to correctly instantiate
SerialInfo annotations with default values even if they are from other modules
and even if they were not processed by the plugin.
#KT-48733 Fixed
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/1574
Leonid Startsev