- This should not affect the performance of the completion, since all
object extensions are collected on the last step, when all main variants
are already collected
- Add more tests
- Also, disable completion of extensions from objects as callable
references (^KT-37395 Fixed)
- ^KT-36860 Fixed
Introduce the notion of contagious for overridable declarations.
So, now overriding uncontagious declaration will not lead to becoming a declaration reachable.
By default, all declarations treated as contagious, it's not the most efficient, but it's safest.
In case when we access a declaration through a fake-override declaration,
the original (real) one will not be marked as contagious, so, later,
other overrides will not be processed unconditionally only because
it overrides a reachable declaration.
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.
Alexander Udalov