Since the declarations generated by compiler plugins do not have proper
PSI (`classOrObjectDeclaration` in this case), we need to resort to
symbols for such declarations to compute the proper qualified name
^KT-65425 Fixed
For destructing calls, the component type is used for the property type
in all cases. However, this can result in runtime and/or compilation
errors when the property is a var and changed, especially when the
component is a primitive but the property type is nullable. Instead,
only use the component type when the property is also a val.
^KT-64944 Fixed
This diagnostic is reported on an explicitly-declared function which
overrides a regular Java function with the same signature as a hidden
one from the same scope.
#KT-64846 Fixed
^KT-62547 Fixed
I also tested the commit by disabling DfaBooleanVariables in all tests
and checking what tests will fail
I didn't find anything that worked in K1, but doesn't work in K2 with
DfaBooleanVariables disabled
Related tests:
- DiagnosticCompilerTestFirTestdataTestGenerated$Resolve$Smartcasts
- LLFirPreresolvedReversedDiagnosticCompilerFirTestDataTestGenerated$Resolve$Smartcasts
- PreFirIdeSpecTestGenerated$NotLinked$Dfa
- DiagnosticCompilerTestFE10TestdataTestGenerated$Tests$SmartCasts
- FirPsiDiagnosticTestGenerated$Resolve$Expresssions.testSyntheticSmartCast
... if the delegate happens to be a function call whose second
argument is a callable reference but not actually a provideDelegate
call.
The fix is to ensure that the call is _actually_ a desugared
provideDelegate call.
This fixes a CCE in a case where the delegate expression is a regular
function call and the second argument is a callable reference.
#KT-65165 Fixed
- `LLFirAbstractSessionFactory` should not load other sessions eagerly
because session creation occurs inside a `computeIfAbsent`, which does
not allow recursive updates to the session cache.
- The issue has not surfaced so far because the default implementation
of `computeIfAbsent` is not sensitive to recursive updates.
^KT-65418 fixed
When a type annotated with @PurelyImplements (explicitly or implicitly)
inherited some methods from a java supertype and the purely implemented
Kotlin supertype, it was inconsistent which of the signatures the
intersection override would have (with or without flexible types).
This commit adds support for the enhancement of intersection overrides.
If one of the overridden methods has non-flexible types, the enhanced
method will have non-flexible types.
This fixes some false negative nullability type mismatches.
#KT-59921 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
This essentially caches topological sort of dependsOn-dependencies in
FirModuleData. Caching it became more necessary after previous commits
that started to call it quite frequently in
VariableStorageImpl.getStability
'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)
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
This reverts commit bb6f466162.
Reverting the fix for KT-57417 as it causes failures in IntelliJ and
Space projects. May reintroduce fix after failures are investigated and
resolved.
When a property is implemented via class delegation, it should be
considered unstable for smart-casting. This is because it is unknown
what kind of stability the underlying class delegate property has. It
could be a stable property, or it could be implemented via a custom
getter and unstable.
^KT-57417 Fixed
This commit extends `LLFirLockProvider` API functionality to provide
`withJumpingLock`, which can be safely used in multithreaded scenarios.
Comparing to regular `withWriteLock`/`withReadLock`, the new API has a
bit more overhead as we have to maintain `jumpingResolutionStatesStack`
and `FirInProcessOfResolvingToJumpingPhaseState` even without contention.
See KDoc of `LLFirLockProvider#withJumpingLockImpl` for implementation
details.
The implicit type phase has been migrated to the new approach, so
now it is safe to drop the last global phase lock.
Potentially, we can have some benefits from migration of other
jumping phases to this API.
^KT-56551 Fixed
^KT-55750 Fixed
A report of UNRESOLVED_REFERENCE should not be made for elements like
FirImplicitThisReference that don't have a source, as they are implicit.
#KT-65044 Fixed
In convertDestructingDeclaration, property delegates are mistakenly
treated as valid expressions for destructuring, but they should be
ignored.
#KT-65021 Fixed
- For synthetic calls
- For delegated constructor calls
Also, I checked that for each toResolvedReference() (beside annotations)
that converts candidate to the resolved reference,
we run `runPCLARelatedTasksForCandidate()` in the same context.
^KT-65103 Fixed
- Move it out of the ContextDependent hierarchy
- Get rid of many controversial checks that were necessary because
Delegate was a ContextDependent inheritor
- Actually fix semantics for lambda processing
Previously, lambdas as delegate expression were not being analyzed
thus leading to an exception (see KT-64635), and this change
forces analyzing them in the same mode as ContextIndependent
(thus `{}` made by default `() -> Unit` leaving to DELEGATE_SPECIAL_FUNCTION_MISSING)
Before this change, new test was failing with an exception.
I've analyzed all `is ContextDependent` and it seems that none of them
is relevant to delegates.
^KT-64635 Fixed
Ivan Kochurkin