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
- The Java functions aren't recognized as candidates during the test
(`FULL_JDK` isn't helping), so I've replicated the tests with local
extension functions and confirmed that they uncover the same
exception.
- Call candidate collection sometimes provides candidate symbols to
`createConeSubstitutorFromTypeArguments` with fewer type parameters
than type arguments provided by `FirQualifiedAccess`, which lead to
an NPE. Because call candidates collected for the purposes of the
Analysis API are best-effort guesses, we can ignore the additional
type arguments.
^KTIJ-23373 fixed
^KTIJ-21506 fixed
For the following example:
```
fun foo(bar: Int) {
<expr>if (bar == 4) return "Four"
else return "Int"</expr>
}
```
AA FE1.0 `isUsedAsExpression` returns `false`.
Since the current AA FIR `isUsedAsExpression` returns `true` for the
above example, this commit fixes it.
- `toResolvedCallableSymbol`: cast defensively because
the resolved symbol might not be a callable symbol.
- `toKtCallInfo`: Check that the resolved symbol is actually callable.
^KTIJ-23003 fixed
- Ensure that typed equals parameter's type is a star projection of
corresponding inline class
- Make possible to declare typed equals that returns 'Nothing'
- Forbid type parameters in typed equals operator declaration
^KT-54909 fixed
^KT-54910 fixed
See: compiler/testData/asJava/lightClasses/
AnnotatedParameterInInnerClassConstructor.kt
The muted tests don't work with the (KT-53371, KT-53519)-related
changes. During this test happens an attempt to access unresolved
annotations via CustomAnnotationTypeAttribute.
Discussion: KTIJ-23547
Dmitriy Novozhilov