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
It's been introduced in the previous commit
("K2: Simplify handling mixed smartcast vs. original candidates")
Because previously, it was assumed wrongly that each next level of
ConeCallConflictResolver filter out the candidates that are 100% less
applicable/specific, but the main one (ConeOverloadConflictResolver)
either leaves the single candidate or the whole same set, thus at
FilteringOutOriginalInPresenceOfSmartCastConeCallConflictResolver
we've got 4 candidates only two of which we might filter out.
There's no real need in binding overrides for smartcast/original members
after FilteringOutOriginalInPresenceOfSmartCastConeCallConflictResolver
Instead, we just create candidates for all of them and filter out after
the ones that came from original type (if needed)
The idea is that when we have successful candidates both from smart cast
and original type, we should discriminate in the favor of former ones.
While this problem (see kt55722.kt) existed before this branch is merged,
initially it was recognized on FP Ultimate when we stopped assuming
captured types from the same projections as equal (see kt55722Initial.kt).
^KT-55722 Fixed
^KT-55024 Fixed
^KT-56283 Related
^KT-56310 Related
It's necessary because even for stable a.b.c.d we can't guarantee that
this reference will always point to the same symbol because
different capture type instantiations generate different scopes
with different resulting symbol instances.
The job is already done at CheckExtensionReceiver resolution stage
And repeating it might only lead to incorrect errors caused by
double-capture of receiver type that leads to contradiction because
in previous commit we started assuming different capture instantiations
as different types.
This is mostly a revert of 2f61a2f56f
There, we erroneously assumed that we may take captured types as equal
if they are based on the same-typed projections.
Each instance of capturing defines its own captured type,
that should not be equal to any other type captured in other place.
Initial motivation was brought by FP Ultimate, where a piece of code
from the new test was found that started working differently after
recent changes.
The most obvious consequence is the change in addAllProjection.fir.kt:
one cannot use an instance as an argument when expected type
is captured type based on the same instance.
Otherwise, it would lead to CCE if we allowed to put arbitrary charsequences
to the list that initially was a MutableList<String>
All other test data changes (but addAllProjection.fir.kt and differentCapturedTypes.kt)
are irrelevant and will be fixed in the subsequent commits
Namely, do not choose `Nothing?` result type when fixing a variable
that has other constraints besides the ones that came from
the relevant type parameter's upper bounds.
See more details in KT-55691.
In K1, the case from specialCallWithMaterializeAndExpectedType.kt
was working (inferred to String?) just because the branches
were analyzed independently with `String?` expected type.
This change became necessary after the previous commit when we united
inference subsystems for if/when branches (see motivation there).
NB: For K1, the behavior is left the same, but the code
was refactored a bit.
^KT-55691 Fixed
^KT-56448 Fixed
Dmitriy Novozhilov