LanguageVersionSettings can be read from the configuration. Also, the
configuration may be used for other stuff, not related to language version
settings, soon
Pass the LanguageVersionSettings instance inside the CompilerConfiguration,
since it's needed anyway. In compiler and tests, the configuration comes from
KotlinCoreEnvironment; in IDE, we're constructing it in JvmAnalyzerFacade
This method is only used within tests, and they didn't fail
mostly by coincidence.
But because of more eager reading of
JvmBuiltIns.isAdditionalBuiltInsFeatureSupported (that checks if built-ins
have been initialized) these tests started failing
A lot of problem arise with current solution
(loading them with lowpriority annotation + additional call checkers):
- We errorneously treated ArrayList.stream as an existing method, while
it's just a fake override from List
- The same problem arises when creating a class delegating to List.
Also the latter case is failing with codegen internal error
(see issue KT-16171)
The negative side of this solution is that instead of reporting meaningful
diagnostic, there will be UNRESOLVED_REFERENCE.
But it seems to be better than having strange problems like ones described above.
#KT-16073 Fixed
#KT-16171 Fixed
General effect will be the following:
- all member scopes for libraries and JDK will be constructed with -language-version/-api-version specified in project settings
- for modules with another (not like in project settings) -api-version or -language-version we will have not correct member scope -- for example we will see typealiases from such libraries.
#KT-15979 Fixed
(cherry picked from commit 0001865)
They're no longer needed because the logic of the decompiler / stub builder is
now trivial (see KotlinJavaScriptDeserializerForDecompiler,
KotlinJavaScriptStubBuilder) and after it's merged to the decompiler for
built-ins, it's going to be tested anyway with BuiltInDecompilerConsistencyTest
Also move internal declarations from runtime.jvm module into new package
kotlin.coroutines.jvm.internal in stdlib
The necessity of these declarations being in built-ins is controversial,
but also it will complicate the migration of current coroutine runtime
to a separate jar if we ever need this
- calls must be prohibited iff they refer to some additonal built in member
- override must be prohibited iff all of the overridden descriptors are additional
Other usages were able to be successfully compiled by 1.0.x
Solution with @Deprecated(level=Error) doesn't work properly, because
deprecation propagates to overridden, thus call 'java.util.ArrayList<String>().stream()'
becomes invalid, while it was correct in 1.0.x
#KT-15794 Fixed
This has no effect for the original use case of mock class descriptors
(unresolved classes used in libraries), but is necessary for pre-release
classes in case the compiler is a release, because such classes end up in scope
and can be the result of the resolution
Alexander Udalov