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
Because composite builds might have isolated classloaders,
therefore caching the MppDependencyProjectStructureMetadataExtractorFactory
on a compositeBuildRoot will lead to ClassCastExceptions
^KT-56712 Verification Pending
`Project.properties` triggers all the properties computation to return them as `Map`. We should query only for a required property instead.
#KT-56421 Fixed
- KT-56505 occurred because `source.getChild(KtNodeTypes.MODIFIER_LIST)`
returns any modifier list in the subtree of the source element, not
necessarily the modifier list belonging to the checked element.
`depth = 1` restricts the search to the modifier list belonging to the
checked element itself.
- For example, given `f1` from KT-56505, `getChild` would return the
modifier list of `public var foo = 0`. Because it contains a
visibility modifier, `f1` wasn't marked with
`NO_EXPLICIT_VISIBILITY_IN_API_MODE`.
^KT-56505 fixed
- In explicit API mode, the `public` visibility modifier is not
redundant unless a declaration is hidden by a container. The
`REDUNDANT_VISIBILITY_MODIFIER` diagnostic is now not reported in such
cases.
^KTIJ-24485 fixed
- `REDUNDANT_MODIFIER_FOR_TARGET` is already reported for `open`
interfaces, but for consistency and IDE support, the compiler now
reports `REDUNDANT_MODALITY_MODIFIER` as well via the extended
checker.
- `REDUNDANT_MODIFIER_FOR_TARGET` cannot be disabled for this case
because it's reported via a basic checker while
`REDUNDANT_MODALITY_MODIFIER` is reported via an extended checker.
- Rename `implicitModality` to `redundantModalities` and return a set of
modalities. The idea of a *single* implicit/redundant modality doesn't
stand up to scrutiny. For example, for interfaces with `ABSTRACT`
implicit modality, `OPEN` is also a redundant modifier. But this is
not necessarily the case for all kinds of declarations.
Hypothetically, if it was possible to declare a class that is abstract
by default, adding an `open` modifier to that class would not be
redundant, as it would make the class instantiable.
There are cases when we have some indices in TypeRegistry left from
previous compilations, so registering new service may increase index
not by one
So such situation is possible:
First compilation (jvm project): register 20 different jvm services in
session + one from compiler plugin (with index 21)
Second compilation (common project): register only 10 common services in
session + one from compiler plugin (with index 21)
*numbers are imaginary
And in this situation increasing `ArrayMapImpl.data` size only one time
may not cover required index
^KT-56685 Fixed
For some synthetic methods from compiled Kotlin classes, it is
not possible to find the PsiElement, when navigating to declaration
in the IDE.
For other methods it works like this:
1. There is a SourceElement with a psi inside
2. Or for K1, the element is searched in the decompiled text
(see ByDescriptorIndexer),
3. Or for K2, the element is searched by Stub taken from metadata
(see FirDeserializedDeclarationSourceProvider)
However, these approaches do not apply to synthetic methods which have
no SourceElement and are not written into decompiled text and metadata.
These are methods values, valueOf, entries from enum and
copy, equals, hashCode, toString from data classes.
Therefore, it was decided to handle their cases separately
at the resolve stage.
Tests (in idea repository):
- org.jetbrains.kotlin.idea.resolve.ReferenceResolveWithLibTestGenerated#testDataClassSyntheticMethods
- org.jetbrains.kotlin.idea.resolve.ReferenceResolveWithLibTestGenerated#testEnumSyntheticMethods
- org.jetbrains.kotlin.idea.fir.resolve.FirReferenceResolveWithLibTestGenerated#testDataClassSyntheticMethods
- org.jetbrains.kotlin.idea.fir.resolve.FirReferenceResolveWithLibTestGenerated#testEnumSyntheticMethods
^KTIJ-24413 Fixed
If you need to mute a test for Gradle IC, the only way is to add exclude pattern and regenerate tests aka remove unnecessary tests. But the filter is absolute, so if you have the same test name in different subfolders (e.g. `pureKotlin/classRemoved/` and `classHierarchyAffected/classRemoved`) you cannot disable only one of them. This commit adds logic to specify which name pattern in which subfolder should be excluded
Support FirStringConcatenationCall in FirCompileTimeConstantEvaluator.
This allows string templates ("foo${bar}") to be evaluated as constants,
assuming the interpolated expressions are themselves constant.
In addition, fixes some handling bugs with KtConstantEvaluationMode,
where some expressions that are not valid in a `const val` declaration
were being supported for `CONSTANT_EXPRESSION_EVALUATION`, including
non-static final Java fields in FIR, and composite expressions of
non-const properties in FE1.0.
Construct compiler plugins classpath based on original
compiler arguments
Support of plugins in full pipeline test allows us to test projects
where some common compiler plugins are used without excluding modules
^KT-56075
Now testData contains info about original compiler arguments, which can
be reused to support plugins and various other arguments
Support original arguments in modularized tests
- Properly support JDK9 modules
- Opt-ins from original arguments
- jdkHome from module data or arguments, as well as noJdk option
- Fix friendPaths not configured
- jvmDefault now handled properly
^KT-56075
^KT-55879
In fact, test-data classpath contains references to stdlib and reflect
already
In order to avoid duplicating libraries on classpath set flags
accordingly
^KT-56075
JS IR BE incremental compilation infrastructure uses
LanguageVersionSettings::toString method to detect if any
compiler features or flags were enabled or disabled.
It is important that the features and flags order are stable
in the result string.
^KT-56580 Fixed
- Replace !! with requireNotNull()
- Add try/catch to wrap all other exceptions (mainly protobuf parser ones)
- Add tests for malformed input for both read and write
- Hide InconsistentMetadataException from public API
- Replace its external usages with IllegalArgumentException
If a synthetic prop clashes with a real property (e.g. @JvmField
property from parent Kotlin class), don't generate fake override for the
synthetic property. This fixes a CONFLICTING_INHERITED_JVM_DECLARATIONS
error in a mixed hierarchy.
^KT-56538 Fixed
Nikolay Lunyak