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.
Use {de,}capitalizeAsciiOnly and to{Lower,Upper}CaseAsciiOnly where
possible, and stdlib's functions with Locale.US everywhere else.
Otherwise, if the default system locale is Turkish, the capital latin
letter "I" is transformed in toLowerCase to "ı" (see
https://github.com/JetBrains/kotlin/blob/66bc142f92085047a1ca64f9a291f0496e33dd98/libraries/stdlib/jvm/test/text/StringJVMTest.kt#L119),
which for example breaks the codegen for `intArrayOf` in
KT-25400/KT-43405.
Similarly, lower case latin letter "i" is transformed to "İ".
#KT-13631 Fixed
#KT-25400 Fixed
#KT-43405 Fixed
- Fix line separator issue
- Always quote args with delimiters (=, :)
- fix one of args files by removing obsolete stdlib reference
- Fix kotlinc.bat to ensure lazy evaluation of additional classpath
Add integration test which checks if only types can be
reprocessed in an incremental round. Also, remove unused
`invalidateTypesForFiles` method.
Furthermore, clarify that types that are reprocessed
(i.e types from .class files) are not necessarily
aggregating types, but simply types that should be reprocessed.
Test: KaptIncrementalWithIsolatingApt.testClasspathChangesCauseTypesToBeReprocessed
This change introduces tracking of generated sources structure in order
to e.g track classpath changes impacting generated sources. This fixes KT-42182.
Also, origin tracking for isolating processors is now using types, allowing
for origin elements from classpath. This fixes KT-34340. However, classpath
origin is used only to invalidate generated files when the type changes and
processing will not be requested for that type. This is in line with the
incap spec.
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
The CompilerMessageLocation is an implicit part of the binary daemon
protocol so changing it breaks compatibility with older daemons.
This change allows to extend location for non-daemon uses without
breaking the binary protocol.
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
Alexander Udalov