Handle case with FirField properly. Previously the code was returning
STABLE_VALUE in that case.
Note that in fact the changed 'when' branch expects only FirJavaField,
as FirFieldImpl should be handled by FirBackingFieldSymbol-check at
the beginning of the method. However, it is impossible to refer to
FirJavaField directly due to module visibility
Enumerate all cases more carefully via exhaustive 'when',
it's more readable and will prevent potential issues in future in case
more subclasses are added.
^KT-58279 Fixed
'getValue' throws if the key isn't present.
Modules without .kt-files might be legitimately absent in inheritorsMap
(see org.jetbrains.kotlin.analysis.low.level.api.fir.compiler.based.SealedClassesInheritorsCaclulatorPreAnalysisHandler)
Previously, such tests were not failing because if a module doesn't
contain .kt-files, then it contains only .java files. And there was
another bug in the tests infra that was essentially folding all the
.java-files in one main-module, effectively shadowing the bug in subject
of this commit.
Previously, the code was calling into
TopDownAnalyzerFacadeForJVM.newModuleSearchScope, which includes
AllJavaSourcesInProjectScope.
This lead to .java-sources being incorrectly attributed to wrong
modules in tests, which, in turn, could've introduced undesired
behaviour around module-dependent checks (e.g. whether a variable
is from the other module and thus can't be smartcasted)
Test ArrayDeque with size 15. With the existing sizes the removeRange
implementation couldn't reach the maximum number of iterations - 3.
Benchmark results for ArrayDeque.subList().clear() that uses
removeRange() can be found here:
https://github.com/qurbonzoda/KotlinArrayDequeBenchmarks/tree/master/results
If we encounter a declaration in the current module whose signature
is the same as that of a declaration in another module which we happen
to also reference from the current module, don't report any errors,
just like we don't do it in Kotlin/JVM. This leaves the user in the KLIB
hell situation, but this is intentional, because otherwise a legitimate
change like moving a declaration to another module and marking
the original one as `@Deprecated("", level = DeprecationLevel.HIDDEN)`
would lead to a error, and we don't want that.
Also, don't try to show the diagnostics on a declaration that doesn't
have an IrFile.
^KT-65063 Fixed
We drop Kotlin function 'remove' or 'getOrDefault' from JvmMappedScope,
if it has platform-dependent annotation, and the bound Java class scope
does not contain a function with the same signature.
#KT-57268 Fixed
When applying function contracts to arguments, make sure the argument
variable hasn't been reassigned within a lambda. Contracts can only be
applied to unchanged variables, otherwise outdated type statements could
be added to the variable.
^KT-63151 Fixed
Postponed lambdas introduce a host of challenges in data-flow analysis.
While inheriting type statements was disabled while these challenges are
being considered, we must still copy type statements from non-postponed
lambda edges. It seems the same is true for implications.
Implications are copied from previous flows when there is only a single
previous flow. That is because it never seemed to be required based on
test results. However, a recent test case revealed that copying is
required when there are multiple previous flows, but only one flow is
from a non-postponed-lambda node.
Combining implications from multiple non-postponed-lambda nodes did not
have an impact on test results, so until such a test case can be
created, the overhead of calculating common implications from multiple
flows will be avoided.
^KT-63351 Fixed
This is done to make the output of "dump-metadata" command consistent
with the output of "dump-metadata-signatures" and "dump-ir-signatures",
which dump signatures for all non-private declarations.
^KT-62340
NB: in order to produce correct IR origins, the source element kinds for
some FIR elements has been changed. As a side effect, mapping PSI to FIR
slightly changed: namely, for `a[b]++`, `a[b]` used to be mapped on
`set` call or callable reference, but now it is mapped on `get` call.
^KT-61891: Fixed
^KT-64387: Fixed
- The compiler's `SealedClassInheritorsProvider` should not be exposed
outside LL FIR, as it is an internal compiler component and also
exposes `FirRegularClass`. `KotlinSealedInheritorsProvider` is an
Analysis API provider for sealed inheritors that accepts a `KtClass`
instead.
^KT-64718 fixed
Dmitry Savvinov