The problem appear because check was performed only on direct children
of sealed class. To fix this, heritage tree is built and used in check
#KT-38989 Fixed
Synthetic property is var when it have setter. The latter is set up
in property when its parameter type is equal to getter return type. In
case of using @Nullable, parameter type of setter is not equal to
return type of getter, because the latter is flexible type. So to fix
this verification should occur using not null types
#KT-39076 Fixed
Stacktrace:
java.lang.RuntimeException: Could not find installation home path. Please reinstall the software.
at com.intellij.openapi.application.PathManager.getHomePath(PathManager.java:106)
at com.intellij.openapi.application.PathManager.getHomePath(PathManager.java:76)
at com.intellij.openapi.application.PathManager.getPreInstalledPluginsPath(PathManager.java:248)
at com.intellij.ide.plugins.DescriptorListLoadingContext.<init>(DescriptorListLoadingContext.java:57)
at com.intellij.ide.plugins.DescriptorListLoadingContext.createSingleDescriptorContext(DescriptorListLoadingContext.java:61)
at com.intellij.ide.plugins.PluginManagerCore.registerExtensionPointAndExtensions(PluginManagerCore.java:1397)
at com.intellij.core.CoreApplicationEnvironment.registerExtensionPointAndExtensions(CoreApplicationEnvironment.java:266)
at org.jetbrains.kotlin.cli.jvm.compiler.CoreApplicationEnvironmentCompatKt.registerExtensionPointAndExtensionsEx(coreApplicationEnvironmentCompat.kt:17)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.registerApplicationExtensionPointsAndExtensionsFrom(KotlinCoreEnvironment.kt:534)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createApplicationEnvironment(KotlinCoreEnvironment.kt:505)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.getOrCreateApplicationEnvironmentForProduction(KotlinCoreEnvironment.kt:465)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:92)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:88)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:76)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:45)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMainNoExit(CLITool.kt:227)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMainNoExit$default(CLITool.kt:225)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMain(CLITool.kt:214)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler$Companion.main(K2JVMCompiler.kt:262)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.main(K2JVMCompiler.kt)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:63)
Don't add `Unit` if variable has an upper constraint T <: A.
It's impossible to coerce variable T to Unit as constraint system will
be always contradictory: T := Unit => Unit should be subtype of A
#KT-39900 Fixed
Before change we've created composite scope for all bounds, which
is incorrect, because intersection of all bounds may be less than
all bounds (see test in commit)
#KT-39032 Fixed
Specialized generated methods for inline classes (toString-impl,
hashCode-impl, equals-impl, etc) are inaccessible from Java, and thus
don't require nullability annotations.
Specialized generated methods for inline classes (toString-impl,
hashCode-impl, equals-impl, etc) are inaccessible from Java, and thus
don't require nullability annotations.
- merge NamedCompilerPhase, SameTypeNamedPhaseWrapper,
AbstractNamedPhaseWrapper and inherit it from SameTypeCompilerPhase
- inline some functions to simplify stacktraces
- reformat and fix inspections
Before that commit we desugared `a ?: b` as
when (val elvis = a) {
null -> b
else -> elvis
}
It was incorrect, because `a` should be resolved in dependent mode,
but when it was `elvis` initializer it was resolved in independent
mode, so we can't infer type for `a` in some complex cases
Nick