FileContentImpl::getPsiFile is not-nullable and at the same time
it contains an explicit case of its fileType to LanguageFileType
that leads to the following exception in case when kt-file is marked as plain text:
java.lang.ClassCastException: com.intellij.openapi.file.exclude.EnforcedPlainTextFileTypeFactory$1 cannot be cast to com.intellij.openapi.fileTypes.LanguageFileType
at com.intellij.util.indexing.FileContentImpl.createFileFromText(FileContentImpl.java:135)
at com.intellij.util.indexing.FileContentImpl.getPsiFile(FileContentImpl.java:104)
#EA-114338 Fixed
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
Nicolay Mitropolsky