- `typeParameterWithTwoBounds.kt` is already present in
`diagnostics/testsWithJvmBackend/duplicateJvmSignature/erasure/`.
- `clashWithCompanionObjectField.kt` is already present in
`codegen/box/fieldRename/jvmFieldNoClash1.kt`.
- `jvmFieldAndJavaGetter.kt` is already present in
`codegen/box/jvmField/noClashWithInheritedJavaMethod.kt`.
In case of two latter tests on JvmField, there's (correctly) no error
reported in JVM IR, which is why those are box tests.
Resolve it like a receiver of a call.
This makes the resolution result consistent with the equivalent
function call.
The K1 difference is covered by KT-66453.
#KT-66504 Fixed
They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
It's not really necessary if the information about if the lambda was a
trailing lambda can be directly saved in FirAnonymousFunctionExpression.
Removing the FIR node uncovered a couple of bugs
(UNINITIALIZED_ENUM_ENTRY, ERROR_IN_CONTRACT_DESCRIPTION) that were
caused by assuming that a lambda is always a trailing lambda.
#KT-66124
Instead, it should happen during BODY_RESOLVE phase.
This fixes KT-66150. The problem was, that `super<B>.f()` expression
in delegated constructor call was transformed during TYPES phase,
and type transformer has no special logic for allowing bare types in
super qualifiers, like the one in expressions transformer (see
`org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirExpressionsResolveTransformer.transformSuperReceiver`).
As a result, `B` without type argument leads to
WrongNumberOfTypeArgumentsError.
It looks incorrect that expressions in constructor call resolved
during TYPES phase, so skipping transformation of
argument list seems like the best solution here.
^KT-66150 Fixed
In most affected tests, the backend diagnostic such as "conflicting JVM
signature" or "accidental override" is directly caused by some already
existing error reported by frontend, so it doesn't make sense to check
backend diagnostics there.
Tests where that was not the case were moved/copied to
`testsWithJvmBackend`.
All of these tests were actually copied to `testsWithJvmBackend` in
866f188120, but it's unclear why they were copied instead of moved. The
test runner for `testsWithJvmBackend` correctly runs the compiler
pipeline and obtains errors reported by the backend, as opposed to the
common diagnostic tests which have a very custom code, using parts of
the old JVM backend, to obtain these diagnostics.
- `require.kt` was added to check JVM accidental override diagnostic
when using the "traits with required classes" feature, which was
removed a long time ago.
- `withErrorTypes.kt` was testing conflicting JVM declarations error (a
backend diagnostic) in presence of error types -- not very useful
scenario because the backend is not run when there's a frontend error.
Basically, just calculate them the same
way it's done for other members.
`chooseIntersectionVisibilityForSymbolsOrNull`
is named like this to prevent a JVM clash.
^KT-66046 Fixed
Use the receiver and context receiver types in addition to the property
name as cache keys for the synthetic property generation.
Also, fix logic that searches for accessor overrides by comparing
receiver and context receiver types.
Finally, let synthetic properties delegate their receiverParameter and
contextReceivers to their accessors.
#KT-65464 Fixed
#KT-66195
The following tests are failing with exceptions and will be fixed in the
following commits
j+k/testKjkPropertyAndExtensionProperty.kt
j+k/testKjkImplicitReturnType.kt
#KT-62118 Fixed
lambdaParameterForBareTypeEarlyFixationAffectsBehavior.kt
should show in the future commits how early variable fixation
necessary for bare type information might affect inference results
^KT-64840 Related
outside of constructor.
In other words, when EXACTLY_ONCE lambda initializes non-static final
field of a class, the lambda has to be inlined, otherwise, backend
generated separate function of separate class for the lambda,
which lead to exception at runtime.
#KT-64854 Fixed
#KT-59906 Fixed
^KT-64187 Fixed
Review: https://jetbrains.team/p/kt/reviews/14807
I also checked that IDE sets metadataCompilation to `true` (Actually, it
looks like IDE performs analysis two times with the flag having
different values, but whatever, maybe it's even better this way)
To be more precises, ResultTypeResolver for K2 now searches for
similar LOWER/UPPER constraints pair based on the same flexible type,
like LOWER(CapturedType&Any..CapturedType?) and UPPER(CapturedType!).
If such a pair is found, the CapturedType is not approximated.
This is done to avoid a big difference between this case and
completely same constraints, like LOWER(CapturedType!) and
UPPER(CapturedType!). In this case we squash them to EQUAL(CapturedType!)
even before ResultTypeResolver, and captured types which is got from
an EQUAL constraint are not approximated even before this commit.
This commit fixes back a case from KT-50134 and a problem with intellij.vcs.git
#KT-65596 Fixed
Alexander Udalov