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
Probably, when NI is there this fix will become unnecessary because
there will be no approximation applied, thus the value parameter
will remain Hello<#Captured> instead of Nothing
#KT-17171 Fixed