This change is needed because otherwise, source files that are not Java will be added as `JavaSourceRoot`, this is incorrect and causes assertion error in `com.intellij.core.JavaCoreProjectEnvironment.addSourcesToClasspath`. Refer to KT-65325 for more context.
Merge-request: KT-MR-14088
Merged-by: Xuan Son Trinh <xuanson.trinh@jetbrains.com>
^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
Local properties defined within the body of a do-while loop can be used
in the condition of the loop. However, use of a `continue` may mean the
property isn't always initialized, even if it is initialized when it is
defined. So while a local property may be within scope and has an
initializer, this doesn't always mean that the property is initialized.
As such, properties that are defined within a do-while loop and also
used in the condition of the same do-while loop should be tracked. Then,
these properties should still be checked for proper initialization even
if they have an initializer.
^KT-64872 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
Remove the ArrayDeque.subList().subList() test for comodification detection.
For types that extend AbstractList and to not override subList function,
the behavior varies depending on JDK version. With JKD8, the test fails for ArrayDeque.
While with JDK9+, it passes.
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
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
Xuan-Son Trinh