Single-letter names were very confusing, especially in declarations like
```kotlin
private inline fun <
reified D : IrDeclaration,
reified ES : IrDelegatingSymbol<AS, D, *>,
reified AS : IrBindableSymbol<*, D>
> finalizeExpectActual(
expectSymbol: ES,
actualSymbol: IrSymbol,
noinline actualizer: (e: D, a: D) -> Unit
)
```
It follows the 877438b1f3 commit removing LV/AV limits for the module and it needed to avoid, for example, cases when `i` is being uppercased to `İ` in the `TR` locale
When BI/incomplete call is present in return argument, it will be
added to the main call-tree, leading to requirement violation in
`ConstraintSystemCompleter.getOrderedAllTypeVariables`
as after `FirBuilderInferenceSession.inferPostponedVariables` it will
be completed, and its type variables couldn't be found anymore
In K1, we actually do the same, but we are able to find type variables
of such calls due to architecture difference:
In K2, `getOrderedAllTypeVariables` uses FIR as the main source to
lookup
In K1, `getOrderedAllTypeVariables` uses resolution atom tree, where
candidate/CS of the call is still available after
`inferPostponedVariables`
In fact, all incomplete calls were analyzed in FULL mode according to
the contract of `FirBuilderInferenceSession.addPartiallyResolvedCall`.
Thus, it means we normally shouldn't add them to the main call-tree, but
accidentally do it as incomplete calls contain non-completed candidate
This particular commit addresses the problem partially, only
in cases when the expected return type for the lambda is Unit and when
the incomplete call is located in the last expression of the lambda
In such cases, we can skip the call from the last expression completely,
since all potential calls there were analyzed in FULL mode,
and couldn't introduce any useful info to the CS of the main call-tree
^KT-54294
So, we're slowly getting rid of the hack with LATE_JDK_SIGNATURES
which is necessary because there's no freshest JDK available at
build agents.
But hope, it would be removed once JDK 21 is there (see KT-58716).
The
`IncrementalJsFirKlibCompilerWithScopeExpansionRunnerTestGenerate
.testSerializedSubClassAndChangedInterfaces`
test fail because the checksums of
the `manifest` files don't match
after the full recompilation.
It happens, because the `b.kt` file may be passed
to the compiler before `a.kt`, in which case while
generating the data class members the compiler
will generate a call to `Any::hashCode` when
accessing the hashcode of the `a` property instead
of generating a call to the fake override
`A::hashCode`.
When working with PSI, the compiler sorts the
input files to at `KotlinCoreEnvironment.kt:200`.
This change removes the flaky
behavior by sorting the input files.
Both explicitly specified and default argument expressions are considered.
In case an argument expression is considered as 'unlinked' the whole annotation
is removed from the declaration. An appropriate compiler warning logged for each
such case.
The reason #1 for this feature is that we want to test IdSignatures
generated for declarations. Currently, there is no (easy) way to ensure
that a change in the signature building logic doesn't cause any breaking
changes wrt klibs.
Now, most IdSignatures include hashed mangled names in them, so even if
we catch a regression where the included hash changes, there would be no
way of knowing immediately what caused it, unless we'd also have mangled
names in the expectations.
The reason #2 is to test the manglers themselves. Currently, there are
no tests for them. They heavily duplicate each other, this is already
causing issues (see KT-57427) that would be very hard to catch without
these tests.
^KT-58238 Fixed
The test is not in any way JVM-specific, but it fails on the JS BE
because of different fq-names of stdlib symbols on JVM and JS.
The fix is in progress. Mute the test until the fix is ready.
Dmitriy Novozhilov