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
Synthetic property accessors are treated as extension functions on Java
classes by the front-end. However, underlying Java accessor methods are
proper members.
There are some cases (superclasses, overridden methods, and so on) where
external dependencies generation can require additional external
dependencies.
* Generate missing IR parameter declarations in external stubs
* Use origin = FAKE_OVERRIDE in external IR stubs for fake overrides
* Set .parent in external IR stubs
* Set .parent in IR generated by some utility methods
Such references require proper scope so that local symbols are bound.
Example:
```
fun <T> outer() {
abstract class ALocal<S : T> {
abstract fun bar()
}
class Local<S : T> : ALocal<S>() {
override fun bar() {}
}
}
```
Here local classes have type parameters with upper bounds depending on
function type parameters, and members overriding members in other local
classes.
Alexander Udalov