This commit is needed for adding targetPlatform serialization for Kotlin Facet Settings Workspace Model on IJ side
Merge-request: KT-MR-11953
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
I don't really know which exact commit fixed this test, but there was
a problem with return types of delegated members. Before my changes
delegated `override fun foo(x: Int)` in `actual class E` had error
return type and now it has correct type `Int`
Group methods of Fir2IrClassifierStorage and Fir2IrClassifiersGenerator
by types of declarations they are working with.
This commit contains nothing but just moving code in borders of the same file
This commit just moves methods which create IR callable declarations
from Fir2IrClassifierStorage to newly created Fir2IrClassifiersGenerator
Code in generators contains some errors (mostly because it refers to the
logic of caching created declaration), and those errors will be fixed
in the following commits
Group methods of Fir2IrDeclarationStorage and Fir2IrCallableDeclarationsGenerator
by types of declarations they are working with.
This commit contains nothing but just moving code in borders of the same file
Restore old behavior of forced creation of fake-overrides
This behavior semantically is not fully correct, because it ignores existed
f/o in storages and overwrites them, but replacing `createIr...` with
`getOrCreate...` leads to problems with f/o in actual classes
^KT-61513
This commit just moves methods, which create IR callable declarations
from Fir2IrDeclarationStorage to newly created Fir2IrCallableDeclarationsGenerator
and Fir2IrLazyDeclarationsGenerator without any modifications.
Code in generators contains some errors (mostly because it refers to the
logic of caching created declaration), and those errors will be fixed
in following commits
If a user has multiple kotlin-stdlib libraries in a project, all those stdlib libraries will contain builtins
which will result in resolution ambiguities.
To prevent such kind of ambiguities inside LLFirDependenciesSymbolProvider,
callables are grouped by facade class name.
Only matching callables from the first facade are used.
Facade is a Kotlin/JVM-term so right now it works only for JVM targets.
Builtins are also used in JVM, so the current solution is to have a Facade name also for builtins.
^KTIJ-26760
If a user has kotlin-stdlib in their project,
the IDE should resolve the builtin declarations to the kotlin-stdlib
instead of builtins from the Kotlin plugin.
^KTIJ-26760
^KT-61039 Fixed
KT-59739 is now open for K1 (but fixed in K2)
Review: https://jetbrains.team/p/kt/reviews/11867/timeline
This partially reverts commit 4f3ecedbca.
Only K1 part is reverted.
Motivation for revert: KT-59739 cannot be properly fixed in K1 because
of the bug it causes - KT-61039
We just accepted that we will have one more "green in K1 -> red in K2"
case
In scope of: KT-22841
Review: https://jetbrains.team/p/kt/reviews/11867/timeline
Reduce complexity by reusing "expect-actual matcher" (namely
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`)
The current solution has worse algorithmic complexity. Previously it was
O(n) in the best case, where `n` is a number of members. Now, it's
O(m^2), where `m` is number of members in one overload group. But we
prefer to have worse complexity but reuse expect-actual matcher, number
of elements in one overload group shall not be big on real world
examples.
The previous logic was non-trivial because it compared types with with
double comparison in `equals`.
Motivation: the discovered false negative in test
changeModalityFromAbstractToOpenInOverride.kt
Unfortunately, it can't be fixed in K1, so we will just live with that.
Luckily, we report ABSTRACT_MEMBER_NOT_IMPLEMENTED additionally.
In K2, MODALITY_CHANGED_IN_NON_FINAL_EXPECT_CLASSIFIER_ACTUALIZATION
will be correctly reported as a compilation error
In scope of: KT-22841
Review: https://jetbrains.team/p/kt/reviews/11867/timeline
`firResolveSession.getTowerContextProvider` should already
contain all the relevant scopes, including default and
importing scopes for the file
Because of this, import and default scopes had presence over the
more local scopes, and the resolve was performed incorrecty - top level
candidates were given higher priority
^KT-61568 Fixed
^KTIJ-26824 Fixed
fixup! Fix `isKotlinFunctionWithBigArity` function
Fix `isKotlinFunctionWithBigArity` function
Previous implementation could return false positive results, e.g. for
class named `abacaba.kotlin.Function42`
^KT-61548: Fixed
Merge-request: KT-MR-11928
Merged-by: Vladislav Grechko <Vladislav.Grechko@jetbrains.com>
Although 'VirtualFile's are typically inside the containing package
directory, e.g. 'foo/bar/Baz.class' for 'foo.bar.Baz', there might
be classes with files in unexpected places. Sources of such classes
may include broken stubs, or just classes from misbehaving IDE plugins.
As we are yet to identity such cases, here we treat them as 'other'
candidates.
Aleksei.Cherepanov