This commits adds a Gradle project property 'kotlin.native.tests.tags',
which can be used when running :native:native.tests:test task to filter
tests by tags. The property value can contain an arbitrary JUnit tag
expression. See
https://junit.org/junit5/docs/current/user-guide/#running-tests-tag-expressions
for more details.
With this task, we can be more sure that TeamCity runs all the tests.
Other test tasks in :native:native.tests project run only tests with
specific pre-defined tags, so running them on TeamCity was discovered to
be more error-prone in that regard, and is generally less flexible.
Don't publish libcurl to a local Maven repo, but consume it directly
as a project dependency.
Publishing appears to be fragile here, and the intention of the test
does not involve checking Gradle anyway.
Initialization of compiler arguments takes a long time because of its copying, but for initial context check, there is no need to do it at all for all targets except Common.
#KTIJ-21161 In Progress
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
Dmitriy Novozhilov