- In contrast to other kinds of dependencies, `dependsOn` dependencies
must be followed transitively.
- Add `transitiveDependsOnDependencies` to `KtModule`. These
dependencies are calculated lazily with a topological sort. They are
added to the dependency provider when it's built in
`LLFirSessionFactory`.
^KT-55329 fixed
^ 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
As 'initialiseVirtualFileFinderServices()' that is run during
test initialization collects transitive dependencies, all of them
must be ready. However, 'KtNotUnderContentRootModuleForTest' has a
built-in dependency provided by 'LLFirBuiltinsSessionFactory'.
^ 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.
^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
- `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).
- `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.
Marco Pennekamp