On CI when populating build cache, the build runs
with --info logging level causing an additional jvm argument
provided to the task.
This argument is usually not provided in local builds.
The argument only affects task printout and not its outputs.
- It became unused after cc70f78027
- And it's not going to become used in the nearest future, since in K2,
we won't have "member scopes" check on frontend (for now)
- Migrate ExpectActualCompatibility -> ExpectActualCheckingCompatibility
where the "checker" is expect
- Migrate ExpectActualCompatibility -> ExpectActualMatchingCompatibility
where the "matching" is expect
KT-62590 in progress. A lot of tests start to fail now. I will fix them
in next commits
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
1. Support variance in ErrorListDiagnosticListRenderer.
I will make some diagnostics to have covariant type arguments in the
next commits
2. Drop unused code
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
It should have been WeakIncompatible from the beginning because it's not
possible to overload by return type in Kotlin
This commit is a step forward to fix KT-62591
Unfortunately, the test cannot demonstrate the problem because of
another bug in K2 KT-59887
^KT-62752 Fixed
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
Motivation:
It makes expect-actual matching-checking model more consistent.
expect-actual "matching" is run before FirResolvePhase.BODY_RESOLVE. You
can't know return types, until you run BODY_RESOLVE. That's why the
return type can't be checked during expect-actual matching. But it's
cursed: you have something that have to match by, but, at the same time,
you can't do it.
expect-actual "checking" is run after FirResolvePhase.BODY_RESOLVE.
That's why if we convert ReturnType incompatibility to WeakIncompatible
(which should have been called CheckingIncompatible), then expect-actual
matching model becomes consistent.
We will also be able to get rid of unnecessary
FirActualCallableDeclarationChecker. Because it won't be necessary.
Return types will be checked by common logic of expect-actual "checker"
Annotation loaders for descriptors (AnnotationAndConstantLoaderImpl) and
stubs (AnnotationLoaderForStubBuilderImpl) share the loading logic until
mapping ProtoBuf.Annotations to output values. The shared logic has been
extracted to the base class.
KTIJ-26761
KTIJ-26961
This fixes a false negative NO_ELSE_IN_WHEN in K2 and incidentally
also fixes a false positive NO_ELSE_IN_WHEN in K1 since the fix is in
the common code.
#KT-62491 Fixed
The meaning of this check is the same as K1
JSCODE_ARGUMENT_SHOULD_BE_CONSTANT and JSCODE_ARGUMENT_NON_CONST_EXPRESSION
diagnostics.
The main difference is that K2 JSCODE_ARGUMENT_NON_CONST_EXPRESSION
diagnostic checks the js() argument in the same way as
const val initializers or annotation arguments are checked.
This means that, the K2 diagnostic is stricter than original
K1 JSCODE_ARGUMENT_SHOULD_BE_CONSTANT diagnostic,
which allows the use of non-constant vals.
^KT-59435 Fixed
Motivation: I'm going to drop NonPrivateCallableAdded (KT-62655) in the
next commits. But I don't want to change the existing logic when I drop
it. That's why I have to introduce the "Unknown" case
This flag will be used on JVM to determine whether or not to generate
external enum entries mappings ("$EntriesMappings") classes. Note that
from the frontend's point of view, every enum has `entries`, so for
backend purposes we have to reach out to the underlying deserialized
data to read the flag from the metadata.
`AbstractSet` is a java class, and it brings flexible types with it.
Because of it, it was possible to write the following code:
```kt
fun usage() {
val mySet = SmartSet.create<String>() // should not contain nulls
mySet += null // compiles because of flexible types
}
```
Using `AbstractMutableSet`
as a base class does not change the implementation,
but explicitly adds a proper kotlin `MutableSet`
interface to the class, making it more type-safe
This includes checking of annotatins set on:
- value parameter types
- type parameter bound types
- extension functions receiver types
- function return types
- class super types
Fix in `defaultParams_inheritanceByDelegation_positive.kt`
is needed because of problem in resolution of implicit return types
(KT-62064), which leads to crash in annotation checker, because it
expects resolved return type.
MR: KT-MR-12245
^KT-60671 Fixed
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation: make sure that cases like KT-62027 won't happen again
Review: https://jetbrains.team/p/kt/reviews/12279/files
Now it's responsibility of the
`createExpectActualTypeParameterSubstitutor` calller to think about the
case when parameters size isn't equal. You must not be able to create a
substitutor if type parameters sizes are not equal
Improvement in `createExpectActualTypeParameterSubstitutor` API also
improves
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`
API.
Because suppose that you accidentally created a redundant wrapping
substitutor => you need to handle the case of not equal type parameters
size on the call site => you start thinking why you should do that on
the call site? It must be a responsibility of
`getCallablesCompatibility` => you realize that you created a redundant
wrapping substitutor
The main reason of this commit is the fact that it makes no sense
to create type checker forks in case of two or more types which equal
each other.
Also, this commit fixes the test taken from KT-59514
(see interconnectedGenerics.kt test changed in this commit).
In this particular case we have a subType of C.WithL<Pr!, En<Pr>!>,
and a superType of R<T> with a superType constructor R.
In findCorrespondingSupertypes we get *two* similar supertypes here,
both have a string representation of:
R<Il<@EnhancedNullability En<Pr>!>!>.
If we create two forks because of it, we get NEW_INFERENCE_ERROR
with the following subtyping violation:
Il<@EnhancedNullability En<Pr>!>! <: En<Pr>!.
NEW_INFERENCE_ERROR happens because we make a redundant fork in that case,
but the forks should still work despite it (see KT-62333).
These two types appear due to the content of FirCorrespondingSupertypeCache.
For a key C.WithL and a superType R it stores the following pair of supertypes:
- R<Il<@EnhancedNullability S>!>
- R<Il<(@EnhancedNullability S & Any, @EnhancedNullability S?)>!>
After substitution of S to En<Pr>! they become similar.
NB: if we change jspecify severity level from strict to warn,
then 'R<Il<(S & Any, S?)>!>' is the only remaining supertype,
and @EnhancedNullability annotation is no more in use.
The type hierarchy in this example looks like:
WithL<T, S> <: CanWithB<T, S>, R.F<S, Il<S>>
CanWithB<T, S> <: R.F<S, Il<S>>
R.F<S, Il<S>> <: R<Il<S>>
So R is reachable by two different ways, via CanWithB and directly via R.F.
#KT-59514 Fixed
Svyatoslav Kuzmich