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
Note that 3 tests are still muted, but for another reason: for FIR
versions of the tests, we need to compile the "pre-release library" with
the next language version which is 2.1. But since currently
LanguageVersion.LATEST_STABLE is 1.9, the compiler refuses to read
metadata of version 2.1, regardless of its own language version. Which
is correct, but it leads to irrelevant errors in the test output -- the
ones about the incompatible metadata version, NOT about the
prereleaseness.
These 3 tests can be unmuted once the default language version is
switched to 2.0.
#KT-60780 Fixed
Before the change, the compiler threw exception in the unmuted tests,
because it tried to load metadata even though it had an unsupported
version. Use the same approach as in K1 (see
DeserializedDescriptorResolver).
Now the tests are unmuted, but note that test data differs from K1. K1
does not report errors related to the class `a.A` because it loads this
class as a _Java class_, so calling its constructor and methods somehow
works. This behavior is questionable since the compiler surely knows
that it is a Kotlin class, but with an unsupported metadata version.
Trying to interpret it as a Java class may lead to subtle problems. So
it's safer for now to avoid loading Kotlin classes with unsupported
metadata versions in K2.
#KT-60795 Fixed
"Container source" means "the source of the container". So, if you
called this extension on a class (`FirClassLikeDeclaration`), it was
reasonable to assume that you would get the source of its _containing
class_, whereas the function actually returned the source of the class
itself.
Instead of inventing another name for this function, I've decided to
inline and remove it because it has only one usage.
Alexander Shabalin