- Introduce new language feature 'ReadDeserializedContracts', which
allows to deserialize contracts from metadata.
- Introduce new language feature 'AllowContractsForCustomFunctions',
which allows reading contracts from sources.
- Use new features instead of combination 'CallsInPlaceEffect ||
ReturnsEffect'
- Rename 'CallsInPlaceEffect' -> 'UseCallsInPlaceEffect',
'ReturnsEffect' -> 'UseReturnsEffect'. As names suggest, they control
if it is allowed to use corresponding effect in analysis.
We have to introduce separate 'ReadDeserializedContracts' to enable
contracts only in some modules of the project, because libraries are
read with project-wide settings (see KT-20692).
Previously files were sorted only when IncrementalDataProvider
was not null to normalize js output in case of incremental compilation.
Because of that an output js file could be different after rebuild
in IC tests.
The issue could be reproduced anywhere, but the tests failed only on
Windows, and it seems tests were not run on Windows for some time.
*.kjsm and other files might be received when FileCollection is
used in Gradle as a dependency.
Example: `testCompile project(":$coroutines_core").sourceSets.test.output`
(a popular-ish solution to introduce dependencies between tests)
It's implemented through Jsr305State while it's not related
to jsr-305 becasue currently it's the most convenient way
to introduce the flag.
Probably, it's worth renaming Jsr305State to something more abstract
like NullabilityAnnotationsConfiguration
#KT-21982 Fixed
This commit makes IC react more granularly on these changes
Precisely, it marks dirty only kt-files that having lookups into
synthetic package built upon a changed layout-file
#KT-21622 Fixed
It's purpose is passing java classes being used during analysis
to incremental compilation to let it track diffs
Potentially it might be done the other way:
incremental compilation could build a separate container to analyze
necessary classes, but it's rather hard to implement now
#KT-17621 In Progress
In kotlin-gradle-plugin, the compiler is invoked with a
K2JVMCompilerArguments instance where both the classpath is set, and the
buildFile is used (containing the same classpath entries in XML).
Previously, the compiler concatenated those two classpaths, which
resulted in duplicated entries, which could slow down compilation. Now,
if buildFile is used, the classpath passed explicitly is ignored
(exactly as, for example, destination ("-d"), which is also stored in
the XML build file).
No test added because there doesn't seem to be any change in
user-visible behavior
Effectively it leads to all stubs being built for any once used package
The idea is that they only were used for FILE_TO_PACKAGE_FRAGMENT
that is mostly read in backend and rarely in the IDE, so we can replace
its usages with searching through related package-fragments
See KT-21328
Compiler removes all files from its output directory.
Due to this reason (and some other reasons) it't not a good idea
to put DCE output to `classes` dir.
Therefore we changed output dir to `$buildDir/kotlin-js-min`.
Additionally, we now allow to customize output dir.
In particular, this fixes issues with webpack in multi-project build +
continuous Gradle build.
This behavior was used until 6a1b6d10d8, where the JDK has
unintentionally started to be added to the end of the list, breaking
code which depended on libraries which bundle something from the JDK
#KT-21299 Fixed
See the previous commit for information on the kotlin-reflect vs
kotlin-reflect-api distinction.
Add kotlin-reflect as an explicit runtime dependency of most of the test
configurations because even though they all depend on tests-common, the
runtime dependency on kotlin-reflect is not exported from tests-common
to other modules because the projectTests dependency is not transitive.
Keep the EnvironmentConfigFiles enum because its values are used in
determining whether the environment is going to be used for JVM or
non-JVM project analysis, but remove the actual files.
Drop EnvironmentConfigFiles.EMPTY and replace its only usage in
preprocessor with JVM_CONFIG_FILES: it's easier and won't affect
anything
Make ScriptDefinitionProvider an interface
and provide different implementation for cli and IDEA
Rework ide extension point to a simpler interface (ScriptDefinitionContributor)
Move template loading logic into a top level function
Allow script definitions to be reloaded in IDE
Ilya Chernikov