Note that there are more places where assertions for inline classes should refined:
- lateinit vars
- values that come from Java
- type casts (interfaces to inline class type)
DeepCopyIrTree: typo fix.
Default arguments: made proper overridden descriptor selection.
Local declarations: made proper determination whether a function is locally defined.
Probably, it would be more correct to skip such lambdas when resolving
the returns' references, but it'd be more complicated and still useless
since non-local returns are impossible in such lambdas
(relevant parameter is noinline)
#KT-22900 Fixed
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
Mikhail Zarechenskiy