The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
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
Denis.Zharkov