Version is written to the plugin.xml in every build so we exclude it to
improve caching.
Add test for kotlin plugin version to checkArtifacts.gradle.kts
tools.jar from JDK has different public api on different platforms which
makes impossible to reuse caches for tasks which depend on it. Since we
can't compile against those classes & stay cross-platform anyway, we
may just exclude them from compile classpath. This should make tools.jar
compatible at least within one build of JDK for different platforms
It's important to have consistent pre_release flag values in the
current and bootstrap compiler. Otherwise, it's possible to publish
release compiler with pre_release artifacts (stdlib, for example) and
vice versa.
Once this test fails, the next step is to advance bootstrap compiler
The problem here is that we have separate bootstrap compiler and
artifacts (stdlib, for example) that are used in tests and implicitly
participate in them.
For example, this test started to fail when bootstrap compiler was
advanced to a version where pre_release flag is enabled. As a result,
dependent stdlib become pre_release as well and now we have additional
error about `Unit` type
In codegen tests on Android, everything is being run with kotlin-reflect
in the classpath. So a package is no longer represented by a
reflect-less PackageReference, but by a full-blown KPackageImpl. Use a
less specific supertype ClassBasedDeclarationContainer instead, the one
which is a supertype of both PackageReference and KPackageImpl, and
which still allows to get the underlying jClass.
This has no effect currently because all class files produced by Kotlin
have the bytecode version in the metadata (currently 1.0.3).
However, this change will allow us to stop writing bytecode version to
metadata in Kotlin 1.5. In fact, we could do it while the default here
was INVALID_VERSION too, but then for example compiling with Kotlin 1.3
against binaries of version 1.5 would lead to extraneous "incompatible
bytecode version" errors (because INVALID_VERSION is basically 0, which
is incompatible to 1.0.3+), in addition to the correct "incompatible
metadata version" error.
The reason why we might want to avoid writing bytecode version is the
fact that the initial use case it was added for is already supported by
the metadata version, and the bytecode version error reporting was never
fully implemented. Actually bytecode version was almost unused because
of that.
Even if a function is known to be tail call because it's a compiler
generated bridge, the tail return might still need to be added in case
of Unit return type.
This is one example of a function replaced by a lowering after
AddContinuationLowering mentioned in the last commit: the lowering that
makes default stubs static is further down. Although this is not a
lambda, calling getOrCreateSuspendFunctionViewIfNeeded on it in the
inliner is fatal all the same.
Delaying suspend view generation until the inliner is not a good idea
because it prevents lowerings after AddContinuationLowering from
further transforming the declarations.
Anton Bannykh