Before const inlining for fields, we actually want to remember a given
field in `InlineConstTracker`. We are doing it already in const
evaluation. So we just need to ignore const inlining in
`CallAndReferenceGenerator` and delegate it to const evaluation.
#KT-60737
The original Java checker has an early return in
case of `resultingDescriptor !is JavaClassConstructorDescriptor`.
It fires if the descriptor is
`TypeAliasConstructorDescriptor`, thus further
diagnostics are not reported.
In `GradleStyleMessagerRenderer.render` method, when there is `location` pointing to some file and coordinates `line:column = 0:0`, then a space between the location and the message was not printed.
#KT-61737 Fixed
This is needed for two purposes:
- sometimes dependencies may differ because of changes in KGP, and it's
better to find it right after version-update commit, not only at remote run
- there is a plan to drop `trusted` section from `verification-metadata.xml`
and always set specific versions of used dependencies even for bootstrap
dependencies, so running it in regular bootstrap update routine won't
allow forgetting about it (see KTI-1374)
Repeatedly linking many smaller bitcode modules into one large is very
slow. We are seeing a 10x improvement by instead linking all the small
modules together first and link the result into the larger main module.
This commit implements this optimization in the
LinkBitcodeDependenciesPhase phase.
^KT-61604 Fixed
Co-authored-by: Johan Bay <jobay@google.com>
This change aligns with the intention in 634279621d, however the "latest" version wasn't synced with other "latest" versions within the repo
#KTI-1349 In Progress
Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
There is a corresponding example inside the stdlib,
see `kotlin.text.startsWith`.
JVM and common counterpart are weakly-compatible
as the actual declaration has default arguments,
which results in `ExpectActualCompatibility.Incompatible.ActualFunctionWithDefaultParameters`
This commit allows such cases.
^KT-61732 fixed
@ImplicitlyActualizedByJvmDeclaration is the only one
OptionalExpectation annotation which works correctly when set only on
`expect`. All other (like @JvmName, @JsName) - not, so warning for them
must be reported.
^KT-61725 Fixed
To avoid collecting context which includes the implicit class receiver,
context for class header positions is collected before entering
the `context.withRegularClass` call