Support FirStringConcatenationCall in FirCompileTimeConstantEvaluator.
This allows string templates ("foo${bar}") to be evaluated as constants,
assuming the interpolated expressions are themselves constant.
In addition, fixes some handling bugs with KtConstantEvaluationMode,
where some expressions that are not valid in a `const val` declaration
were being supported for `CONSTANT_EXPRESSION_EVALUATION`, including
non-static final Java fields in FIR, and composite expressions of
non-const properties in FE1.0.
- KTIJ-24574 occurred because a local destructuring declaration was
erroneously returned as the non-local containing declaration of an
element by `getNonLocalContainingOrThisDeclaration`. This occurred in
`init` blocks.
KTIJ-24574 fixed
Use expanded ConeTypes to get correct parameters and return types
Also, fix the order of rendering modifiers in `KtFunctionalTypeRenderer`
^KTIJ-24527 Fixed
For the following example, when we run the reference shortener, it
drops `a.b.c` qualifier, because it matches "FOURTH".
```
package a.b.c
fun <T, E, D> foo(a: T, b: E, c: D) = a.hashCode() + b.hashCode() + c.hashCode() // FIRST
fun <E> E.foo() = hashCode() // SECOND
object Receiver {
fun <T, E, D> foo(a: T, b: E, c: D) = a.hashCode() + b.hashCode() + c.hashCode() // THIRD
fun foo(a: Int, b: Boolean, c: String) = a.hashCode() + b.hashCode() + c.hashCode() // FOURTH
fun test(): Int {
fun foo(a: Int, b: Boolean, c: Int) = a + b.hashCode() + c // FIFTH
return <expr>a.b.c.foo(1, false, "bar")</expr>
}
}
```
As shown in the above example, when SHORTEN_IF_ALEADY_IMPORTED option is
given from a user, the reference shortener has to check whether it can
drop the qualifier without changing the referenced symbol and if it is
possible to do that without adding a new import directive, it deletes
the qualifier.
It needs two steps:
1. Collect all candidate symbols matching the signature e.g., function
arguments / type arguments
2. Determine whether the referenced symbol has the highest reference
priority when we drops the qualifier depending on scopes
This commit uses `AllCandidatesResolver(shorteningContext.analysisSession.useSiteSession).
getAllCandidates( .. fake FIR call/property-access ..)` for step1.
For step2, we use a heuristic based on scopes of candidates. If a
candidate symbol is under the same scope with the target expression, it
has a `FirLocalScope` which has the high priority. So when we have a
candidate under a `FirLocalScope` and the actual referenced symbol is
different from the candidate, we must avoid dropping its qualifier
because the shortening will change its semantics i.e., reference.
The order of scopes depending on their scope types is:
1. FirLocalScope
2. FirClassUseSiteMemberScope / FirNestedClassifierScope
3. FirExplicitSimpleImportingScope
4. FirPackageMemberScope
5. others
Note that for "others" the above rule can be wrong. Please update it if
you find other scopes that have a priority higher than the specified
scopes.
One of non-trivial parts is the priority among multiple
FirClassUseSiteMemberScope and FirNestedClassifierScope. They are
basically scopes for class declarations. We decide their priorities
based on the distance of class declaration from the target expression.
Note that we take a strict approach to reject all false positive. For
example, when we are not sure, we don't shorten it to avoid changing its
semantics.
TODO: One corner case is handling receivers. We have to update
```
private fun shortenIfAlreadyImported(
firQualifiedAccess: FirQualifiedAccess,
calledSymbol: FirCallableSymbol<*>,
expressionInScope: KtExpression,
): Boolean
```
The current implementation cannot handle the following example:
```
package foo
class Foo {
fun test() {
// It references FIRST. Removing `foo` lets it reference SECOND.
<caret>foo.myRun {
42
}
}
}
inline fun <R> myRun(block: () -> R): R = block() // FIRST
inline fun <T, R> T.myRun(block: T.() -> R): R = block() // SECOND
```
Tests related to TODO:
- analysis/analysis-api/testData/components/referenceShortener/referenceShortener/receiver2.kt
- analysis/analysis-api/testData/components/referenceShortener/referenceShortener/receiver3.kt
FirReferenceResolveHelper internally checks whether the referenced class
id matches the qualifed access or not. If they do not match, it reports
an error. When the companion object has the same name as the class,
resolving a qualified expression access to a member of the companion
object causes an error because of the mismatch e.g.,
```
package my.sample
class Test {
fun a() {
my.sample.<caret>Test.say()
}
companion object Test {
fun say() {}
}
}
```
This commit fixes the issue.
TODO: When the companion object has a name difference from class, it
does not report an error but the resolution result is wrong in FIR. See
KT-56167.
---
Commentary from rebaser: the issue mentioned in this code is
fixed in 71a368e06e, so the actual
fix is omitted, and only test data is preserved
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
and assert that symbol is not a substitution/intersection override
in the `compute` method otherwise.
Because `fakeOverrideSubstitution` should be calculated for all real
implicit types, no call to this method should actually happen.
Otherwise, it can be problematic to create a session
which would contain the full designation path:
`provider.getFirCallableContainerFile(symbol)`
returns `firFile` of a super class which might be from module `a`,
when declaration and its outer classes are from module `b`.
^KTIJ-24105
^ 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
Jiaxiang Chen