@ImplicitlyActualizedByJvmDeclaration is the only one
OptionalExpectation annotation which works correctly when set only on
`expect`. All other (like @JvmName, @JsName) - not, so warning for them
must be reported.
^KT-61725 Fixed
To avoid collecting context which includes the implicit class receiver,
context for class header positions is collected before entering
the `context.withRegularClass` call
Note that 3 tests are still muted, but for another reason: for FIR
versions of the tests, we need to compile the "pre-release library" with
the next language version which is 2.1. But since currently
LanguageVersion.LATEST_STABLE is 1.9, the compiler refuses to read
metadata of version 2.1, regardless of its own language version. Which
is correct, but it leads to irrelevant errors in the test output -- the
ones about the incompatible metadata version, NOT about the
prereleaseness.
These 3 tests can be unmuted once the default language version is
switched to 2.0.
#KT-60780 Fixed
Before the change, the compiler threw exception in the unmuted tests,
because it tried to load metadata even though it had an unsupported
version. Use the same approach as in K1 (see
DeserializedDescriptorResolver).
Now the tests are unmuted, but note that test data differs from K1. K1
does not report errors related to the class `a.A` because it loads this
class as a _Java class_, so calling its constructor and methods somehow
works. This behavior is questionable since the compiler surely knows
that it is a Kotlin class, but with an unsupported metadata version.
Trying to interpret it as a Java class may lead to subtle problems. So
it's safer for now to avoid loading Kotlin classes with unsupported
metadata versions in K2.
#KT-60795 Fixed
"Container source" means "the source of the container". So, if you
called this extension on a class (`FirClassLikeDeclaration`), it was
reasonable to assume that you would get the source of its _containing
class_, whereas the function actually returned the source of the class
itself.
Instead of inventing another name for this function, I've decided to
inline and remove it because it has only one usage.
IllegalArgumentException: class
org.jetbrains.kotlin.psi.KtLambdaArgument is not a subtype of class
org.jetbrains.kotlin.psi.KtExpression for factory
TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM
was reported when TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM was
reported on a FirLambdaArgumentExpression, report it on its
`expression` instead.
#KT-60380 Fixed
Previously, If we had multiple overloads of the same function in the same file,
then `LLFirProvider.SymbolProvider.getTopLevelPropertySymbols`
might be called with multiple copies of the same `KtFile`,
thus providing multiple copies of the same `FirNamedFunctionSymbol`.
It might be reproduced when `LLFirCombinedKotlinSymbolProvider` is used
and if nobody accessed `LLFirProvider.SymbolProvider` without a context.
A wrong result with multiple duplicating symbols will be cached in this case.
The commit fixes KT-61683 as `ConeOverloadConflictResolver` prefers actuals over expects
only in a case of valid code when an actual has a single corresponding expect.
It was not true because of the bug; thus, the problem from KT-61683 arose.
^KT-61683 fixed
There was only one real inheritor of AbstractFirBaseDiagnosticTest,
so there is no need in the whole hierarchy of abstract test runners
Also AbstractFirOldFrontendLightClassesTest is not intended to check any
diagnostics or CFG dumps, so this logic was removed (they still can be
checked using non-legacy AbstractFirDiagnosticTest from the main test
infrastructure)
^KT-61640 Fixed
This change doesn't affect any tests in the moment, because it's part of
bigger refactoring of proper storing IR declarations during FIR2IR
conversion (KT-61637)
Without this change, there is one test break in branch for KT-61637:
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.testJavaMethodWithTypeParameter
This is needed for two reasons:
1. common and platform modules are analyzed in the same setup with same
dependencies and configurations, so the results of the enhancement for
any function will be completely identical. So by sharing enhanced
symbol storage, we avoid recomputation enhanced functions and improve
performance
2. There is a goal to have some unique key for IR declarations in FIR2IR.
For regular declarations, the key is just Fir symbol, and for fake-overrides
it is a pair of original symbol and fake override owners lookup tag.
But for enhanced functions the symbol is not unique, because we create
different symbols for the same enhanced function for different modules.
So this change fixes this problem
^KT-60397 Fixed
This change doesn't affect any tests in the moment, because it's part of
bigger refactoring of proper storing IR declarations during FIR2IR
conversion (KT-61637)
Without this change, there are some test breaks in branch for KT-61637:
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.testStarImportOfExpectEnumWithActualTypeAlias
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.DefaultArguments.testNestedEnumEntryValue
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.Basic.testEnumEntryNameCall
Kirill Rakhman