They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
It's not really necessary if the information about if the lambda was a
trailing lambda can be directly saved in FirAnonymousFunctionExpression.
Removing the FIR node uncovered a couple of bugs
(UNINITIALIZED_ENUM_ENTRY, ERROR_IN_CONTRACT_DESCRIPTION) that were
caused by assuming that a lambda is always a trailing lambda.
#KT-66124
A wrapper block was introduced as a part of fixing KT-59748, but was
assigned a real source, which had `getOrBuildFir` confused because
of the incorrectly built `KtToFirMapping`
It is relevant for:
- `if`, `when` expressions with an assignment as a single expression
- Kotlin code fragments,
when the assignment is being analysed as a single expression
in the fragment
^KT-66411 Fixed
Script parameters now can be resolved independently of the script.
But, as parameters are part of the script, their resolve will be called
before the script.
^KT-66276 Fixed
This element has been introduced to simplify resolution logic in LL FIR,
but now this element is redundant and only complicates the code as after
KT-56683 `FirFile` has real phases
^KT-65876 Fixed
The base class in scripting considered obsolete and therefore supported
via some ad-hoc mechanisms. In particular parameters to the base class
c-tor are passed via script provided properties. But in combination
with the resolution logic, this leads to issues described in KT-60452
This commits filters out such parameters from script resolution
scope and avoids this problem for now.
Bot it should be noted that proper diagnostics for properties shadowing
should still be implemented - see #KT-65809
#KT-60452 fixed
This change is required to properly support such declarations in lazy
resolution mode as we usually replaced initializers with lazy
expressions during the body calculation phase
^KT-62840
This change is required to properly support such declarations in lazy
resolution mode as we usually replaced initializers with lazy
expressions during the body calculation phase
^KT-62840
Now we can resolve this generated property in the same way
as other regular properties.
This is the pre-step for independent script initializers
^KT-65344
^KT-65523
We should use the source from replaced `FirAnonymousInitializer` as it
is more equivalent. Another point – the previous implementation
duplicated the source between generated FirProperty and initializer
^KT-65344
NB: in order to produce correct IR origins, the source element kinds for
some FIR elements has been changed. As a side effect, mapping PSI to FIR
slightly changed: namely, for `a[b]++`, `a[b]` used to be mapped on
`set` call or callable reference, but now it is mapped on `get` call.
^KT-61891: Fixed
^KT-64387: Fixed
FirConstExpression is usually confused with "constant" calculations,
while in fact, it just denotes a simple literal expression
and `1 + 1` isn't represented by a FirConstExpression.
^KT-64314 Fixed
Java resolving subsystem requires calculated visibility for correct disambiguation of supertypes.
But visibility remains `Unknown` for Kotlin class-like declarations during supertypes resolving because `STATUS` resolve phase is performed after `SUPER_TYPES` phase.
To fix the problem, the visibility should be initialized to public at the FIR building phase if no modifier is presented.
^KT-64127 Fixed
findClasses works over regular `PsiElementFinder`, which doesn't know
about out ClassId conception. So, `a/b/A.B` and `a/b/A/B` are the same
from `FqName` point of view.
`FirJavaFacade` has this check, so this problem appears only in the case
of combined provider.
^KT-62892 Fixed
This commit is Low Level FIR part of changes around propagated
annotations (aka foreign annotations).
It includes such changes as:
* implicit type phase postpones foreign annotations resolution
* annotation arguments are requests resolution for postponed
annotations from implicit type phase as a pre-resolve step
* body resolve phase just calls lazy resolution for foreign annotations
on demand
* isResolved check for type annotations to be sure that all annotations
are resolved after annotation arguments phase
^KT-63042 Fixed
^KT-63681 Fixed
We shouldn't transform annotations not from declaration side due to
a possible different context and to avoid unexpected transformation of
unrelated declarations
Example:
```kotlin
fun implicitType1() = TopLevelObject.expectedType()
object TopLevelObject {
private const val privateConstVal = "privateConstVal"
fun expectedType(): @Anno(privateConstVal) Int = 4
}
```
Here we will try to transform the annotation from `expectedType`
during `implicitType1` and as the result, we will see unresolved
reference on the declaration side. This commit fixes this issue.
This solution is based on the fact that the compiler anyway will
resolve the propagated annotation on the declaration side.
And it doesn't matter if it is resolved before or after the call site
declaration transformation, because as a global result, we will observe
that all declarations are resolved correctly in the right context.
Hence, this commit fixes the issue in the case of "full resolution"
which is true for the compiler, but it is not correct for Low Level
FIR where we resolve declarations on demand. It will be solved in
the next commits
^KT-63042
We should share the original instance to be able to later resolve it in
the original context. This commit returns the KT-60387 problem, but the
root cause (concurrent modification) will be fixed in the context of
KT-63042
^KT-63042
Now there are no real unresolved imports - all imports are considered
resolved starting from the IMPORTS phase and until they are proven
otherwise in the checkers.
Because of that, some `UNRESOLVED_REFERENCE` diagnostics are gone -
in the cases when such references were actually resolved through
those unsupported imports.
The compilation of incorrect files should not be affected by this,
the checkers would still prevent the compilation of the files with
incorrect imports.
But now the references to the declarations from such imports no longer
will be highlighted as unresolved references.
Review: https://jetbrains.team/p/kt/reviews/13244
Motivation: Performance. When I fix KT-59887 in later commits, I will
make actual-to-expect resolve to work not only for actual declarations.
Considering that LLFirExpectActualMatcherLazyResolver worked even for
non-KMP projects that might be a potential performance regression
FirExpectActualMatcherProcessor in the compiler does the same thing (it
checks for MultiPlatformProjects before running the transformer)
This is required to have stable resolution order to avoid concurrent
modifications and correct resolution context.
This also fixes KT-63700 as a super call expands only during body
resolution in the case of secondary constructor
^KT-63042
^KT-63700 Fixed
This is required to have stable resolution order to avoid concurrent
modifications.
Another point here – status phase logic for componentN function is
located in the corresponding property resolution
^KT-63042
Previously, this call was required to avoid sharing to have independent
instances with their own resolution cycle. Now we will have stable
order (in the next commit), so it is possible to share instances.
Also, this change makes the logic consistency with Light Tree
^KT-63042
From one side to check how annotation propagation works and from another
side to cover scenarios with lazy resolution from type position as it is
a valid case of usage in Analysis API (KtFirAnnotationListForType)
^KT-63042
Kirill Rakhman