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
`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
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>
Lowering asks whether to generate getter/setter call only when it should
be present. It means the code define explicit getter or setter.
And it seems correct to use it instead of trying direct field access.
The same way as `FirClassUseSiteMemberScope` is present
when there is an implicit receiver with a pure Kotlin type,
`JavaClassMembersEnhancementScope` is present when
the receiver's type comes from Java sources
^KTIJ-26785 Fixed
We shouldn't process other elements (like parameters/receivers) because
we can't modify them anyway. This will help to avoid exceptions like
```
Attempt to load text for binary file which doesn't have a decompiler plugged in
```
in tests
^KT-61431
Otherwise, it will throw exception like:
```
IllegalStateException: No 'FirJvmTypeMapper'
```
Anyway, PsiType is JVM conception, so it is not supposed to be used
outside the JVM platform
^KT-60318
Reporting it for `VIRTUAL_MEMBER_HIDDEN`
is ok, because `VIRTUAL_MEMBER_HIDDEN`
has always been an error, so we are
allowed to treat these as overrides
implicitly.
^KT-59408 Fixed
^KT-59419 Fixed
^KT-57076 Fixed
Originally it was named createModuleFragmentWithSignaturesIfNeeded, because
there was a counterpart `...WithoutSignatures`. Now that function has
gone and there is only one entrypoint left
If some function is not fake-override, then its type should be just
default type of containing class
For fake overrides the default type calculated in the following way:
1. Find first overridden function, which is not fake override
2. Take its containing class
3. Find supertype of current containing class with type constructor of
class from step 2
^KT-60252 Fixed
single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
'CodeFragmentCapturedValueAnalyzer' assumes the analyzed code fragment
is then passed to the backend. For property calls, there are several
code generation strategies (field, accessor, delegate). In order to
be able to choose one, the whole property, including its possibly
'const' initializer, must be resolved.
The commit fixes a plenty of 'FirIdeNormalAnalysisSourceModuleCompilerF\
acilityTestGenerated.CodeFragments.Capturing' tests that broke after
the 'FirExpression.type' refactoring.
Ilya Kirillov