The logic of the AllOpen compiler plugin for opening classes and opening
declarations of classes does not match. This leads to declarations being
open when the containing class is not open. There is a warning reported,
for exactly this situation.
However, creating meta-annotations of AllOpen annotation is quite common
in certain ecosystems. In particular, Spring. This can lead to a warning
if the meta-annotation has properties.
Align the class kind check for members, so they are not opened if the
containing class cannot be opened.
^KT-63507 Fixed
The AllOpen compiler plugin opens all declarations of the annotated
class, regardless of class type. However, it only opens classes (not
interfaces, objects, enums, etc). This leads to a warning where members
of an annotation are open when annotated. Spring has many such
annotations, as it is common to create meta-annotations from the core
set of AllOpen supported annotations.
^KT-63507
These tests are mostly used to check ABI in case you're compiling a
library or library-like code, which is no longer possible (since old JVM
backend is only used in the IDE).
The AllOpen plugin can make private members open. But for private
properties, they can be considered stable for smart-casting if they do
not have a custom getter.
#KT-58049 Fixed
Sometimes when running MPP tests we may
observe js-specific modules running with
the jvm-specific fir2ir converter
(probably because the name didn't contain
the JVM affix).
- added also 'kotlin-allopen-compiler-plugin-embeddable' to be used with
'kotlin-compiler-embeddable'
- 'kotlin-maven-allopen' now just depends on
'kotlin-allopen-compiler-plugin' instead of "embeding" it into itself
^KT-52811 In Progress
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
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
This inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.
The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.
The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").
The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.
^KT-55840 Fixed
Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
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
AllOpen plugin makes the properties all-open, but the annotation class
is left closed, because allopen for k2 literally checks
`classKind == CLASS`.
Since the properties are open, a
`NON_FINAL_MEMBER_IN_FINAL_CLASS` diagnostic is reported for them. It's
positioning strategy seeks for the explicit `open` modifier which is
not present.
The added test should not crash the compiler.
^KT-54260 Fixed
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
Original `ComponentRegistrar` exposes Project to its registration method,
so plugins should manually register extensions to it. To prepare for
possible unbound compiler from Project API in future new `K2ComponentRegistrar`
introduced which provides registration method without Project at all
- `ParentAnnotatedWith` matches declarations, which parent is annotated
- `HasAnnotatedWith` matches declarations, which have at least one
direct child with annotation
Also, `DeclarationPredicate.Any` is removed, because there is no
intention to support lookup for all declarations in module
^KT-52486 Fixed
This scheme will be common for all compiler plugins with K1 and K2 support:
- `plugin-common` contains classes shared with K1 and K2 implementations (if any)
- `plugin-k1` contains implementation for K1 compiler
- `plugin-k2` contains implementation for K2 compiler
- `plugin-backend` contains implementation for backend extensions (if any)
- `plugin-cli` is module for registration of plugin in CLI compiler
- `plugin` is a root module with tests and all submodules embedded
This structure is needed to distinguish parts related to different frontends,
which is needed for proper dependencies settings for Kotlin IDE plugins
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Since IDEA moved most of it's jars to java 11 it's illegal to use them
in our dependencies, so all modules which use `intellijDep()` should
carefully specify which jars they use
Brian Norman