ensure fir annotations are included in FirDanglingModifierList and resolved,
dedicated DanglingTopLevelModifierListStructureElement exists for top
level lists only, class level lists are processed by containing structure
element
k1 would suggest `get` as well
but with current fir structure with fake desugaring
get is moved to the separate fake psi which doesn't exist
thus the problem is ignored for now
^ KTIJ-24025
`candidateSymbol` has any reasonable meaning only for references with
not completed candidate, so this property is moved from FirNamedReference
to new node FirNamedReferenceWithCandidateSymbol, which has real
implementation only in :resolve module (`FirNamedReferenceWithCandidate`)
- `context(...)` is a modifier that must precede annotations and other
modifiers, so for declarations it is rendered in
`renderAnnotationsAndModifiers`.
- Ignore `@ContextFunctionTypeParams` in the annotation list of FE10
types, as the annotation is an implementation detail of context
receivers in K1 and shouldn't be rendered.
^KT-55098 fixed
- Context receivers in function types may not be labeled, so the created
`KtContextReceiver`s have `null` labels. Such labels currently only
compile due to a bug (see KT-55187).
Now annotations are resolved with following algorithm:
1. On COMPILER_REQUIRED_ANNOTATIONS we resolve all annotations
and store results if this is compiler annotation, plugin annotation,
or annotation with meta-annotation (meta annotations are checked
recursively with designated resolution if needed)
2. On TYPES stage we resolve all those annotations once again and if
some annotation changes resolution then we keep type from p.1 and
report error on this annotation, so user should disambiguate it
Ambiguity may occur because of nested annotations with same name as
plugin annotations:
```
annotation class SomeAnnotation // (1) plugin annotation
open class Base {
annotation class SomeAnnotation // (2)
}
class Derived : Base() {
@SomeAnnotation // <-----------------
class Inner
}
```
At COMPILER_REQUIRED_ANNOTATIONS annotation call will be resolved to (1)
because at this stage supertypes are not resolved yet, and we consider
only importing scopes. At the TYPES stage we will find correct
annotation from supertype
- `unwrap` signals that fake overrides will be unwrapped until the
original symbol is recovered.
- Also remove nullability of the returned `KtCallableSymbol`. If the
given symbol cannot be unwrapped, it is most likely already the
original symbol.
- Remove the lazy resolve to `STATUS` in `KtFirOverrideInfoProvider`, as
it's not needed to unwrap fake overrides.
- Add a checker which ensures that property accesses have no explicit
type arguments. If an error on the property access's callee reference
already exists, the new error is not reported in favor of the existing
error, as the property access may have been intended to be a function
call.
- `complicatedLTGT.fir.kt`: The underlying parser issue is not yet
solved, which is why `x` is parsed as a property access with explicit
type arguments.
- `reservedExpressionSyntax` tests: This new check makes a lot of the
access expressions in these tests illegal, so valid lines have been
added and invalid lines appropriately marked with
`EXPLICIT_TYPE_ARGUMENTS_IN_PROPERTY_ACCESS` errors.
^KT-54978 fixed
Fe10:
* supported default setter
* support default getter
* support parameter from default setter
Fir:
* support java synthetic properties
* support parameter from default setter
^KT-54051
^KTIJ-23669
FirErrorFunctions are created for unknown labels
when the code in return statements is not complete yet.
Such labels cannot be resolved, and no symbols should be created for them
^KTIJ-23421
hide explicit builtins to reveal target platform dependencies.
Otherwise, `expect` class from builtin of e.g. JDK
would be found instead of actual dependency from Kotlin Runtime
aleksandrina-streltsova