Add a special annotation @JsExternalTypeArgument for
marking function parameters. The marked parameter
accepts an argument with an external type only.
^KT-57479 Fixed
This commit sets a list of `KtElement` as the return type of
`ShortenCommand::invokeShortening()`. It allows us to take the result
i.e., shortened PSIs. This can be used, for example, when we want to
run code-format only on the shortened PSI after running the reference
shortener.
^KT-57636 Fixed
If property call receiver is something real (like another property or a
function call), then it should not be shortened because the semantics
might change
^KTIJ-25232 Fixed
The existing K2 reference shortener collects all the PSI elements to
shorten. As a result, it possibly shortens duplicated PSI elements. For
example,
```
// FILE: main.kt
package a.b.c
fun test(n: Int) {
return if (<expr>x.y.z.Outer.Inner.VALUE0 > x.y.z.Outer.Inner.VALUE1</expr>) 1
else n
}
// FILE: values.kt
package x.y.z
class Outer {
object Inner {
val VALUE0 = 13
val VALUE1 = 17
}
}
```
for the above code, the existing K2 reference shortener tried to shorten
- x.y.z.Outer.Inner -> Inner
- x.y.z.Outer.Inner.VALUE0 -> VALUE0
- x.y.z.Outer.Inner -> Inner
- x.y.z.Outer.Inner.VALUE1 -> VALUE1
`x.y.z.Outer.Inner` is included in the list to shorten twice.
When it actually shortens the PSI elements, it shortens only
- x.y.z.Outer.Inner.VALUE0 -> VALUE0
- x.y.z.Outer.Inner.VALUE1 -> VALUE1
but it imports all of
- x.y.z.Outer.Inner
- x.y.z.Outer.Inner.VALUE0
- x.y.z.Outer.Inner.VALUE1
As a result, it has unnecessary additional import directives.
This commit fixes the issue by avoiding duplicated shortening for a
single PSI element.
The change in `FirDiagnosticsHandler` ensures
`DEBUG_INFO_DYNAMIC` is still reported in
`FirPsiJsOldFrontendDiagnosticsTestGenerated.testConventions`.
Support `SPREAD_OPERATOR_IN_DYNAMIC_CALL` and
`WRONG_OPERATION_WITH_DYNAMIC`
Add a special annotation @JsExternalInheritorsOnly for marking
external interfaces and classes. The marked interface or class
can’t be a parent for non external interfaces, classes or objects.
^KT-57423 Fixed
The compiler should only report diagnostics for
comparisons over builtins and identity-less types,
other incompatibilities should be reported
via inspections.
It's ok that in `equalityChecksOnIntegerTypes`
instead of `EQUALITY_NOT_APPLICABLE_WARNING` we get
`EQUALITY_NOT_APPLICABLE`, because
`ProperEqualityChecksInBuilderInferenceCalls`
is already active by default.
This change also replaces the notion of a representative superclass
with the least upper bound.
This makes complex types like
intersection/flexible transparent to
RULES1-based compatibility checks.
One way to look at it is to think
that this is an automatic way of handling
type parameters: automatic picking of
"interesting" bounds, and checking them against one another.
Note that `TypeIntersector.intersectTypes`
for `Int` and `T` where `T` is a type parameter
may return both `{Int & T}` or `null`
depending on `T`-s bounds. At the same time,
for type parameters `T` and `K` it will
always return `{T & K}`.
`ConeTypeIntersector.intersectTypes`, on the
other hand, will always return `{Int & T}`
irrespectively of the bounds. Meaning, the two
intersectors differ in corner cases.
`lowerBoundIfFlexible` call in `isLiterallyTypeParameter` is backed by
the `equalityOfFlexibleTypeParameters` test.
^KT-35134 #fixed-in-k2
^KT-22499 #fixed-in-k2
^KT-46383 #fixed-in-k2
In a lot of cases, when we want to process the
declaration in scope, it should be resolved to at least TYPES phase.
To avoid doing it manually in all our variety of scopes, we do it when the scope it created.
It was implicitly working manually before as lazy resolve did a lot of extra work
on resolving a declaration it was not supposed to resolve.
Now it's not the case, and we have to explicitly resolve all the declarations we need.
^KT-56543
Co-authored-by: Ilya Kirillov <ilya.kirillov@jetbrains.com>
We can't reduce resolve to COMPILER_REQUIRED_ANNOTATIONS phase for
annotations with arguments, because currently they don't have
argument mapping
```stracktrace
org.jetbrains.kotlin.utils.KotlinExceptionWithAttachments: By now the annotations argument mapping should have been resolved
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.mapAnnotationParameters(firAnnotationUtils.kt:137)
at org.jetbrains.kotlin.analysis.api.fir.FirUtilsKt.toKtAnnotationApplication(FirUtils.kt:79)
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.annotationsByClassId(firAnnotationUtils.kt:60)
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.annotationsByClassId$default(firAnnotationUtils.kt:46)
```
^KT-57424 Fixed
The 'CachingKtAnalysisSessionProvider' was only used in
'KtFirAnalysisSessionProvider', and reasons why it was created
(reusing code between FE10 and K2 session provider implementations)
is not actual anymore.
- Instead of extending the API with `typeParameterNames`, this commit
creates a PSI-based Java type parameter symbol similarly to the
PSI-based Java class symbol. Because completion requires only the type
parameter name, this approach works fine, and without exposing an
optimization via the API.
- Instead of spreading `equals` and `hashCode` implementations over
`KtFirNamedClassOrObjectSymbol` and `KtFirPsiJavaClassSymbol`, this
commit introduces a shared base class.
- Some completion tests failed because the `hashCode` of
`KtFirNamedClassOrObjectSymbol` and `KtFirPsiJavaClassSymbol` was
different for symbols which should be equal. Both symbols now use the
`ClassId` hash code.
- `KtFirNamedClassOrObjectSymbol.equals` is now properly symmetric with
`KtFirPsiJavaClassSymbol`.
- `KtFirPsiJavaClassSymbol` now has a definite class ID, which
simplifies its implementation a little. `KtFirPsiJavaClassSymbol`
doesn't support local Java classes by design.
- Most Java classes aren't deprecated. To avoid building `firSymbol`
in such cases, this commit adds a simple heuristic which checks the
class's annotations for the presence of one of the deprecation
annotations recognized by the Kotlin compiler.
- Note that annotations are compared via simple names, so there is a
slight margin of error. However, comparing class IDs is more costly in
my tests, because getting an annotation's class ID is not as cheap as
getting its simple name.
- Completion accesses symbol type parameters to render their names.
Instead of building the whole list of type parameters, and
consequently the whole FIR class, completion can now access the type
parameter names directly.
- `KtFirVisibilityChecker` accessed `KtFirPsiJavaClassSymbol.firSymbol`
a significant number of times during completion, which led to many
instances of FIR class construction.
- This commit introduces a heuristic to `KtFirVisibilityChecker`
specifically for `KtFirPsiJavaClassSymbol` to bypass the compiler's
visibility checker. The fact that we're dealing with Java class
visibility from Kotlin makes this feasible without reimplementing the
full logic of `FirVisibilityChecker`.
Jinseong Jeon