^ KTIJ-24385
Temp property to store receiver is generated for `a.b++` expression.
If this property's psi corresponds to receiver expr, then FirProperty
would be found by mapper if receiver is requested.
It works unexpectedly, because FirProperty is normally not expected by expression.
This change set fake sources for generated FirProperty, so it won't be found
by source psi
^ KTIJ-24373
when resolving selector expr of a dot qualified expression,
parent qualified expression is resolved
see `KtFirCallResolver.getContainingDotQualifiedExpressionForSelectorExpression`,
Fir is filled with the data. Then,
during final mapping from Fir -> psi, one need to perform the opposite:
take `selectionExpression` to get the initial KtCallExpression
Render KFunctionN and KSuspendFunctionN by their class names, rather
than using arrow syntax. These types have additional functionality
beyond purely being able to invoke them (e.g. getting the name of the
referred function), so using arrow syntax throws away that functionality
and may cause breakages in the resulting code.
Adds implementation and tests for the new
KtClassOrObjectSymbol.annotationApplicableTargets property on
KtSymbolInfoProvider. This implementation delegates to the canonical
implementation in AnnotationChecker for FE1.0, and to the implementation
in FirAnnotationHelpers for FIR.
This change also includes direct tests for annotationApplicableTargets,
and a fix for FirClassLikeSymbol.getAllowedAnnotationTargets in
FirAnnotationHelpers.
Introduce an extension method to retrieve the set of applicable targets
for an annotation, given the annotation class's symbol.
This extension on `KtSymbolInfoProvider` causes a large amount of churn
in test data files, so this change starts off by introducing the
property and always making it return null. A future change will
introduce the actual behavior change, and will include the testdata
changes for the few tests that actually return useful data for this
property.
^KT-55788
Test `parameter_jvmInline.kt` is removed because now members with value
classes are not included in light classes and don't have PSI representation
This requires plumbing a Fe10AnalysisContext through to the
KtFe10AnnotationsList, so that the context's module descriptor and
KotlinBuiltIns instance can be used to look up types correctly.
This eliminates the difference between the FIR and FE1.0 AA
implementations with regards to annotation spread argument handling.
This changes FirAnnotationValueConverter to no longer rely on PSI
information when projecting annotation parameter information to AA.
For annotations defined in Java, including many meta-annotations, PSI
information is not available for the annotation. This caused those
annotation values to be projected as KtUnsupportedAnnotationValue.
Instead of using PSI information, this changes
FirAnnotationValueConverter to use the tree structure instead. Spread
and named parameter arguments are spliced into the parameter list of
their surrounding vararg calls, meaning that callers see the expected
structure. (See the varargSpreadParameter.kt test file for an example.)
This test ensures that annotations on other annotations are properly
handled, even if those annotations are defined in Java rather than in
Kotlin.
Note that this functionality only works on FIR, and currently has bugs
that mean the result is an error type. Follow-on changes will fix the
error-type bug, and restore proper functionality for FIR.
Previously, the `KtFirUsualClassType.qualifiers` was empty for the local classes
The reason was a RawFirBuilder setting up a containingClassForLocalAttr
to the outer non-local class for the local class. It should be a null instead,
see the localClassType.kt as an example
^KT-55510 fixed
- If too few or too many type arguments were provided, they were all
thrown away in `TypeArgumentMapping`,
`FirCallCompletionResultsWriterTransformer`, and `KtFirCallResolver`.
The fix handles type arguments of the wrong arity more gracefully.
- Note for `TypeArgumentMapping`: Excess type arguments are not needed
for candidate resolution. Excess type arguments are still resolved
due to the handling in `FirCallCompletionResultsWriterTransformer`.
- Post-processing in `AllCandidatesResolver`: When all candidates are
resolved in `AllCandidatesResolver.getAllCandidates`, the function
builds a FIR file. During that resolution, the
`generic<String, String>` call (in example
`functionCallWithTooFewTypeArguments.kt`) is correctly marked as
inapplicable, but the missing type argument is inferred as an error
type. `firFile` then contains a function call
`generic<String, String, ERROR>` instead of `generic<String, String>`.
This call is still marked as inapplicable. Despite that, the
*subsequent* resolution by
`bodyResolveComponents.callResolve.collectAllCandidates` disregards
the call's inapplicability and resolves successfully into an
applicable candidate. This is because `CandidateFactory` doesn't make
any guarantees for already inapplicable calls. The fix adds
post-processing to `AllCandidatesResolver` to preserve candidate
inapplicability.
- Most tests that this commit changes had slightly different results due
to type arguments becoming resolvable.
- `wrongNumberOfTypeArguments.kt` and
`wrongNumberOfArgumentsInTypeAliasConstructor.kt`:
`ConeDiagnostic.toFirDiagnostics` prefers specific errors. Because
`ARGUMENT_TYPE_MISMATCH` is specific and `INAPPLICABLE_CANDIDATE` is
not, only the former is reported. I see no reason to pass an illegally
typed argument in either test, so the change reduces the errors to
`INAPPLICABLE_CANDIDATE`.
- `typeAliasSamAdapterConstructors2.fir.kt`: See KT-55007.
- Disable `mismatchTypeParameters` JS backend test due to its handling
of excess type arguments. See KT-55250.
^KT-54980 fixed
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
In K1 analogue of `K2_VISIBILITY_ERROR` is `K1_RUNTIME_ERROR`, so
candidates with `K2_VISIBILITY_ERROR` should win over innaplicable
candidates with `INAPPLICABLE`, `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
or `INAPPLICABLE_WRONG_RECEIVER` applicability
This is needed to allow resolution to invisible symbols (and later
suppress error with `@Suppress("INVISIBLE_SYMBOL", "INVISIBLE_REFERENCE")`
^KT-55026 Fixed
^KT-55234
- `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
Review: https://jetbrains.team/p/kt/reviews/7652
Put this change into a separate commit because:
1. The change is boring and clutters the diff of the first commit
2. The first commits is already too big
Roman Golyshev