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
Stability of the language version is used for example to determine
whether the PRE_RELEASE_CLASS diagnostic should be reported. Now that
there are pre-release classes in the standard library (Experimental et
al.), we'd like to avoid this error on their usages in diagnostic tests
which are using the "!API_VERSION: 1.3" directive
- Into PrimitiveNumberRangeLiteralRangeValue modifies how bounded
value are created by checking if the high bound range can be modified
to be exclusive instead of inclusive such as the generated code will
be optimized.
- Add black box tests checking that the specialization does not fail
on any kind of arrays.
- Add a bytecode test checking that the code is correctly optimized.
Fix of https://youtrack.jetbrains.com/issue/KT-22334
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
In an open expected class inheriting an expected interface, abstract
members are now inherited as _open_ fake overrides, not final. Final was
technically safer but also stricter and thus could be unexpected by the
user. In a final class, abstract members are still inherited as _final_
fake overrides. So, the general rule is now the following: the modality
of an expected fake override, which overrides only abstract members, in
a non-abstract class is equal to the modality of that class
#KT-22031 Fixed
Mikhael Bogdanov