It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
In strict mode, an exception will be thrown when inconsistent metadata is encountered. In lenient mode, the reader will attempt to handle the inconsistent metadata by ignoring certain inconsistencies. This is a solution to a problem of reading metadata 'from the future' that is not allowed by default, but desired in certain cases. See updated ReadMe for details.
Also fix problem with Strict Semantics flag.
#KT-57922 Fixed
#KT-59441 Fixed
Previously, because we didn't handle flexible types properly in
prepareCapturedType, projections inside flexible types would only be
captured during subtyping with captureStatus=FOR_SUBTYPING
which would lead to the constraint type being wrongly approximated
(see ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint).
Fixing the capturing produced two kinds of false positive diagnostics:
1. In ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint we would get two instances of cone types
that are structurally equal and containing the same captured type.
However, because we only skipped subtyping if the types were
referentially equal, we would get a contradiction here.
The fix was to use structural equality instead, which should be okay
as the captured type instances are the same.
2. Reified type variables were inferred to captured types because
flexible arrays with captured upper bounds
(Array<Foo>..Array<Captured(out Foo)>?) were not properly approximated.
#KT-62609 Fixed
FirDefaultArgumentsInExpectActualizedByFakeOverrideChecker is an adhoc
checker which can be converted to ExpectActualCheckingCompatibility to
reuse common expect-actual checking infrastructure.
^KT-62913 Fixed
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
Tests that were broken by one of my previous commits are now fixed:
- actualFakeOverride_paramsAreCompatibleViaSharedMethodWithDefaultParams.kt
- inheritedJavaMembers.kt
DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE diagnostic
disappeared in delegation.fir.kt because only one
AbstractExpectActualChecker incompatibility can be reported at a time
(DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE is now reported
not by adhoc checker but by common AbstractExpectActualChecker). It
would be nice to report both of them, but it's a separate issue KT-62631
delegation2 test makes sure that
DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE is reported when
NO_ACTUAL_CLASS_MEMBER_FOR_EXPECTED_CLASS is fixed
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
Alexander.Likhachev