Rework how built-in types are loaded in compiler for JVM

In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.

To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.

Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.

 #KT-19227 Fixed
 #KT-28198 Fixed
This commit is contained in:
Alexander Udalov
2017-07-14 20:07:01 +03:00
parent 8ce7742e7c
commit ed86757817
35 changed files with 179 additions and 132 deletions
+2 -3
View File
@@ -1,6 +1,5 @@
Usage: kotlinc-jvm <options> <source files>
where advanced options include:
-Xadd-compiler-builtins Add definitions of built-in declarations to the compilation classpath (useful with -no-stdlib)
-Xadd-modules=<module[,]> Root modules to resolve in addition to the initial modules,
or all modules on the module path if <module> is ALL-MODULE-PATH
-Xassertions={always-enable|always-disable|jvm|legacy}
@@ -40,8 +39,6 @@ where advanced options include:
in the interface (annotating an existing method can break binary compatibility)
-Xjvm-default=compatibility Allow usages of @JvmDefault; generate a compatibility accessor
in the 'DefaultImpls' class in addition to the interface method
-Xload-builtins-from-dependencies
Load definitions of built-in declarations from module dependencies, instead of from the compiler
-Xno-call-assertions Don't generate not-null assertions for arguments of platform types
-Xno-exception-on-explicit-equals-for-boxed-null
Do not throw NPE on explicit 'equals' call for null receiver of platform boxed primitive type
@@ -62,6 +59,8 @@ where advanced options include:
-Xsupport-compatqual-checker-framework-annotations=enable|disable
Specify behavior for Checker Framework compatqual annotations (NullableDecl/NonNullDecl).
Default value is 'enable'
-Xsuppress-missing-builtins-error
Suppress the "cannot access built-in declaration" error (useful with -no-stdlib)
-Xuse-ir Use the IR backend
-Xuse-javac Use javac for Java source and class files analysis
-Xuse-old-class-files-reading Use old class files reading implementation. This may slow down the build and cause problems with Groovy interop.
+7 -4
View File
@@ -1,10 +1,13 @@
compiler/testData/cli/jvm/noStdlib.kt:1:8: error: unresolved reference: kotlin
import kotlin.reflect.*
^
compiler/testData/cli/jvm/noStdlib.kt:4:5: error: cannot access built-in declaration 'kotlin.String'. Ensure that you have a dependency on the Kotlin standard library
String::class.primaryConstructor
^
compiler/testData/cli/jvm/noStdlib.kt:4:19: error: unresolved reference: primaryConstructor
String::class.primaryConstructor
^
compiler/testData/cli/jvm/noStdlib.kt:6:11: error: unresolved reference: isExternal
compiler/testData/cli/jvm/noStdlib.kt:6:7: error: cannot access built-in declaration 'kotlin.Unit'. Ensure that you have a dependency on the Kotlin standard library
::foo.isExternal
^
compiler/testData/cli/jvm/noStdlib.kt:6:11: error: cannot access built-in declaration 'kotlin.reflect.KFunction0'. Ensure that you have a dependency on the Kotlin standard library
::foo.isExternal
^
compiler/testData/cli/jvm/noStdlib.kt:7:5: error: unresolved reference: listOf