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.
In complex projects, there might be several library copies (with the
same or different versions). As there is no way to build a reliable
dependency graph between libraries, a project library depends on all
other libraries. As a result, there might be several declarations in the
classpath with the same name and signature.
Normally, K2 issues a 'resolution ambiguity' error on calls to such
libraries. It is acceptable for resolution, as resolution errors are
never shown in the library code. However, the backend, to which
'evaluate expression' needs to pass FIR afterwards, is not designed for
compiling ambiguous (and non-completed) calls.
Currently, the test files are only analyzed as source code, and present
errors do not affect code fragment analysis. In the following commits,
however, the test files will be compiled to test code fragment
analysis against library sources.
One of the compiler lowerings, namely `PropertyReferenceLowering`,
optimizes usages of property references in some cases,
and if a containing delegated property accessor is inline,
it might need this accessor's bytecode.
If an accessor function is defined in a different module,
IDE tries to acquire its bytecode via the index, however,
the index doesn't cover classfiles from compiler output,
and that leads to errors like KTIJ-26706 and IDEA-320283.
One of the ways to ensure that the bytecode exists is to include files
that contain inline accessors in the compilation process. For example,
if file f1.kt from the analysis result contains property `val p by D()`,
and `D.getValue` is an inline function defined in file f2.kt,
then f2.kt must be present in the analysis result.
If f2.kt contains another property `val q by E()`,
and `E.getValue` is an inline function defined in f3.kt,
then f3.kt must be present in the analysis result. And so on.
Fixes KTIJ-26706, IDEA-320283
Merge-request: KT-MR-11793
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
The only case when erasure matters in a context of materialization of
`PromisedValue` is when the type is a type parameter which upper bound
is an inline class. Since `PromisedValue::materializeAt` is a hot spot
and `eraseTypeParameters` is an expensive operation, we should not do
type erasure in other cases.
Dmitriy Novozhilov