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
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
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
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
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
This still doesn't work for unresolved delegate (see analysis/low-level-api-fir/testData/getOrBuildFir/wholeDeclaration/localDelegatedPropertyWithPropagatedType.out_of_src_roots.txt)
^KT-63042
We should process generated property as a part of the primary constructor.
This was already implemented in 8387ea8a, but some parts were missed.
ClassDiagnosticRetriever:
* dropped relation to properties generated from constructor parameters
as they should belong to the primary constructor only
* accurate logic to fully visit an implicit primary constructor to be
able to process nested declarations (e.g., inside a super type call)
SingleNonLocalDeclarationDiagnosticRetriever:
* add relation to generated properties as now they fully belong to
the constructor
FileElementFactory:
* dropped explicit resolution of generated properties from a constructor
* added explicit resolution of generated enum members for consistency.
Effectively, this is not required because we don't have compiler
checkers for such generated enum member declarations
ClassDeclarationStructureElement:
* do not collect mapping for generated properties from constructor
* explicitly declare that we should process only ClassDelegationField
^KT-62437 Fixed
Dmitrii Gridin