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>
Otherwise, when we come to `ClassCodegen.kt:173
for `GradleActionTest` and check
`FUN FAKE_OVERRIDE name:<get-project>`,
we then go to `JvmSignatureClashDetector.kt:37`,
and call `mapRawSignature(overriddenFunction)`
which ignores the original `@JvmName`.
It does so because it relies on the property copy
which forgets to copy the getter, but
`@get:JvmName` is stored in it.
Extra when-branches for `FAKE_OVERRIDE` are needed,
because otherwise the annotations would not
be copied in `Fir2IrDeclarationStorage.kt:723`.
Extra when-branches for `DELEGATED_MEMBER` are
needed, because otherwise the generated IR changes
in some tests. For example, see:
`FirLightTreeIrTextTestGenerated.Declarations.testKt35550`.
The `assumesBackingField`-related change is backed by
the `FirLightTreeIrTextTestGenerated.Stubs.testJavaEnum` test.
`this.body = null` ensures the resulting IR
matches K1.
The change in `FirImplicitBodyResolve.kt` is needed,
because otherwise the bootstrap compiler fails at
`:compiler:frontend:compileKotlin`,
but I didn't come up with a smaller test for it.
If we don't make an explicit accessor copy,
then when we later create a `Fir2IrLazyPropertyAccessor`
for the fake override getter, it's `fir` will
be a reference to the `FirProperty`, not `FirPropertyAccessor`.
That's why `DumpIrTreeVisitor` will render `IntrinsicConstEvaluation` as
a getter annotation as well.
`FirPsiIrTextTestGenerated.testDelegatedGenericImplementation`
renders type parameters from `<get-x>`,
because when assigning `extensionReceiverParameter`
of the setter `<set-x>` we come to
`Fir2IrClassifierStorage.kt:638`,
and in this cache there's the parameter with
the `<get-x>` parent.
Note that `typeContext.origin == DEFAULT` in
`getCachedIrTypeParameter`.
It's `DEFAULT` because at the line `Fir2IrDeclarationStorage.kt:335`
the `function` variable is `null` (because there's no setter).
The change in `declarationAttributes.kt` is backed
by the `FirPsiIrTextTestGenerated.testKt45853` test.
^KT-57104 Fixed
^KT-57432 Fixed
Merge-request: KT-MR-9210
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
- Dependency symbol providers contained a lot of useless
`FirExtensionSyntheticFunctionInterfaceProvider`s, because such a
provider only generates function classes from compiler plugins. If
there aren't any such `FunctionTypeKind`s in the session, there is no
need to even add the provider.
- `FirExtensionSyntheticFunctionInterfaceProvider`s that are added to
the list of dependency providers despite this optimization will now be
combined in `LLFirCombinedSyntheticFunctionSymbolProvider`. It checks
`ClassId` heuristics once, which is more efficient than checking them
in every provider separately.
with dedicated opt-in language feature and special
annotation or module capability.
Not intended for a general use, solves specific K/N
scenario with interop libs.
#KT-55902 fixed
The basic idea is that during deserialization/loading compiled
Java classes, there might be some of the dependencies absent that
are referenced from enum arguments in annotations.
Such situation is not considered as totally ill-formed, thus supporting
it, allowing to read the names of mentioned in the annotation argument
might be useful for Java enhancement
^KT-56656 In Progress
Remove a bunch of custom logic to determine when a callable reference is
bound or not (and hence mustn't have a receiver). Instead, a helper
extension is introduced to determine when a callable reference is bound
by checking if dispatch/extensionReceiver is not FirNoReceiver and the
referenced member is not static.
#KT-57253 Fixed
If an intersection override overrides members A.x, B.x and C.x and
B <: A, then A.x is subsumed by B.x, and we don't add it to the list of
overridden members. This fixes a false-positive MANY_IMPL_MEMBER_NOT_
IMPLEMENTED where an implementation is subsumed by an abstract override.
^KT-57092 Fixed
The implementation is rather limited. Advanced cases, such as
replacing a script with another one with different import directives,
won't work because of non-trivial relationship between 'FirFile' and
'FirScript'.
`supportsEnumEntries` in `EnumCLassLowering` is not really
needed, but it was left just in case.
Both K1 and K2 ensure the feature is
enabled before they generate IR.
`supportsEnumEntries` is not enough, because the frontend will not
generate `entries` if `kotlin.enums.EnumEntries` is not available
(linking against an outdated stdlib is considered a valid use-case).
From the resolution point of view,
it's OK to resolve into `entries` while
the feature is off, because then K1 reports an error on the call site.
^KT-56687 Fixed
^KT-55614 Fixed
The expression needs to be resolved first to determine if there is a
receiver that needs to be extracted to a temporary variable. Also, the
special case for prefix increment/decrement on local variable without
delegates requires resolution to check if the variable is local.
^KT-56771 Fixed
^KT-56659 Fixed
Annotation arguments that are resolved in COMPILER_REQUIRED_ANNOTATIONS
phase are resolved again in ANNOTATION_ARGUMENTS phase. If they resolve
to a different symbol, report an error.
KT-56177
If an annotation doesn't specify an explicit use-site target,
previously it was added to both, the primary constructor value parameter
and the property in the FIR. Then, in FIR2IR, only the "correct" one was
added to the IR. Move up the deduplication logic into the frontend.
^KT-56177 Fixed
This flag is true by default but is set to false for
- Java methods and constructors
- interface delegation methods that delegate to Java
The NAMED_ARGUMENTS_NOT_ALLOWED logic is mostly refactored to use the
new flag though some custom logic remains for determining the correct
message and to work around a corner case with fake overrides.
The flag is (de)serialized from/to metadata. For backward compatibility
with K1, delegated methods to Java types are deserialized as stable.
^KT-40480 Fixed
Dmitrii Gridin