- In performance tests, modification trackers were incorrectly
incremented between tests for binary modules even with library caches
enabled. The new option `includeBinaryTrackers` can be used by
performance tests to exclude binary modules.
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
This is the way it works in K1.
See `OverloadingConflictResolver.kt:345`.
^KT-57568 Fixed
Merge-request: KT-MR-9395
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Why did the problem existed?
At first, lambdas were analyzed with suspend function expected type,
because it's the WHEN-case and we propagate expected type info to
the branches.
Then, after the lambdas was introduced to the containing inference
system, we're creating ResolvedLambdaAtom using the information
from analyzed lambda's shape, but didn't use known lambda resulting
type (from which we might infer FunctionTypeKind).
So, the fix is just using that already obtained information.
^KT-57446 Fixed
The only case when behavior is change is described at
computeNonTrivialTypeArgumentForScopeSubstitutor
The idea is to avoid depending on the presence of @UnsafeVariance
and instead approximate captured types in covariant argument positions
before building substitution scopes
It's correct because for Captured(*) <: Supertype,
Out<Captured(*)> <: Out<Supertype> and when we've got @UnsafeVariance
value parameters at Out, it's ok to allow passing Supertype there.
^KT-57602 Fixed
^KT-54894 Fixed
- An `OptionalAnnotationClassesProvider` only needs to be created if the
package part provider may even have optional annotation classes.
- In the IDE case, the package part provider never provides optional
annotation classes, so especially in the IDE, we can avoid a lot of
useless symbol providers with this.
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>
- If the callee reference in a desugared compound assignment was an
error reference, the compound assignment wasn't cached by
`FirElementsRecorder`. This led to KTIJ-24895 (see the issue for more
details).
- The solution falls back on the compound assignment's source to decide
`isSourceForCompoundAccess`, as an operation name can be reconstructed
from the PSI.
^KTIJ-24895 fixed
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
Marco Pennekamp