See the test added: there's a non-denotable T!! type inside flexible type
that wasn't handled before.
ConeKotlinType::contains handles flexible types content and some other cases
Also, it has better asymptotics
Currently, KaptGenerateStubsTask may not generate KDoc comments
correctly. See KT-43593 for more details.
This commit provides a Kapt flag called
`kapt.keep.kdoc.comments.in.stubs`
to control whether KDoc comments will be included in the generated
stubs.
This flag is currently enabled by default to keep the existing behavior
and avoid breaking existing users.
Users who don't need KDoc comments in stubs but are hitting KT-43593 can
disable the flag.
Whether this flag will be disabled by default later is to be determined.
Bug: https://youtrack.jetbrains.com/issue/KT-43593
(Note that this commit only provides a workaround, it doesn't
actually fix the bug.)
Test: (Ir)ClassFileToSourceStubConverterTestGenerated#testCommentsRemoved
Use the position in the source file if possible, and
only if the members are coming from other source files,
use their name and descriptor. This is necessary in order
to ensure deterministic output in clean and incremental
runs, while preserving the order of members in the sources.
Class methods and fields are currently sorted at serialization (see
DescriptorSerializer.sort) and at deserialization (see
DeserializedMemberScope.OptimizedImplementation#addMembers). Therefore,
the contents of the generated stub files are sorted in incremental
builds but not in clean builds.
The consequence is that the contents of the generated stub files may not
be consistent across a clean build and an incremental build, making the
build non-deterministic and dependent tasks run unnecessarily (see
KT-40882).
To work around that, this commit sorts class methods and fields when
outputting stub files.
Bug: KT-40882 (there are actually 2 issues in here; this commit fixes
the first one)
Test: New DeterministicBuildIT + Updated existing test expectation files
For classes with companion objects, Kotlin compiler generates a 'Companion' static accessor field.
Java prioritizes fields over inner types (apparently, Scala does this as well, KT-29864), so the generated initializer doesn't compile.
As a workaround, initializer generatation is disabled for enum fields inside companion objects. Certainly, it's not a proper fix, however it does fix the regression.
KAPT was relying on clearing JarFileFactory to make sure
annotation processing does not hold onto annotation processing
classpath once done. Once KAPT switched to using Gradle workers, multiple
KAPT runs were sharing the same class loader ie. the same version
of JarFileFactory. Clearing the cache resulted in race condition,
as some runs were unable to load processors from jars.
This commit fixes this problem by avoiding the use of ServiceLoader
which was causing the issue. Jars would be added to the cache, but
they would never be removed. That's why JarFileFactory had to be
clearned manually. By loading the processor names manually (simply
exploring the classpath), no file handles leak.
Fixes https://youtrack.jetbrains.com/issue/KT-34604
Test: verified against the test project from the bug
Put initializers on fields when corresponding primary constructor
parameters have a default value specified. The new behavior
is available under the new 'DUMP_DEFAULT_PARAMETER_VALUES' flag.
Note that this doesn't affect regular functions with default parameter
values, as well as primary constructor parameters without a
'val' or 'var' keyword.
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
Andrey Zinovyev