These warnings are technically correct but are too noisy and have little
value in case a user explicitly specifies unstable API version: it's
unlikely that seeing these warnings, the user will choose to rollback to
an earlier API version, since new API is probably one of the reasons
that user specified that unstable version to begin with.
So, in "kotlinc -language-version 1.3 -api-version 1.3 -cp
kotlin-stdlib-1.2.jar", we will no longer report a warning that the
attached stdlib has a version older than explicit API version (so long
as 1.3 remains unstable).
Note that we _could_ have reported these warnings in "kotlinc
-language-version 1.3 -cp kotlin-stdlib-1.2.jar", because in this case
the user might've not even be concerned with the new API in 1.3 and was
only looking for new language features. However, we still think that
it'd be unnecessary and one opt-in to the experimental world (with
LV=1.3 in this case) is enough
#KT-22777 Fixed
API version inference happens in
JvmRuntimeVersionsConsistencyChecker.checkCompilerClasspathConsistency
only in the case when API version is specified explicitly (with
"-api-version ..."). However, if the user specifies "-language-version
1.3", what's likely meant is "-language-version 1.3 -api-version 1.3",
and it would be unwise to infer API version to 1.2 (which is the version
of the attached stdlib) in this case.
Therefore, API version is now considered to be specified explicitly if
_either_ -language-version or -api-version is specified on the command
line
#KT-22777 In Progress
Now ExpectActualDeclarationChecker in IDE context
uses common module descriptors for relevant checks.
Compiler still uses own module instead (see comment in checker)
So #KT-21771 Fixed
- 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
Pavel V. Talanov