Inject LanguageVersionSettings instead; all information relevant to the
analysis should be now passed via an instance of LanguageVersionSettings
(which should be renamed to a more general name in the future).
This is partially a revert of d499998 and related commits
This makes it possible to drop CompilerConfiguration from
CallCheckerContext, which in turn helps to avoid passing the entire
CompilerConfiguration instance through front-end
Previously JvmTarget was declared in module 'util' which is accessible
for example from 'frontend', which is not very good.
Also add a superinterface named TargetPlatformVersion which is going to
be used in platform-independent injectors in 'frontend' in the following
commits. Use it in one place (LanguageVersionSettingsProviderImpl.kt)
instead of DescriptionAware because TargetPlatformVersion sounds like a
better abstraction than DescriptionAware here
When synthetic member comes not from the receiver type itself,
but from one of its supertypes it doesn't make sense to subsitute
the member with receiver type, we should obtain relevant supertype
and use it instead.
#KT-16578 Fixed
Previously ReflectionTypes.find returned an error class in case a class
is not found in the module dependencies. The problem with this approach
is that each call site should call ErrorUtils.isError on the result and
report an error if needed, in order to stop this type from reaching the
codegen, which can't handle error types.
Now we create a MockClassDescriptor instance instead. It's not an error
class, so it'll be handled correctly in the codegen. Also its scope is
empty and errors are reported on any non-trivial usage (see
MissingDependencyClassChecker), so this approach is not worse than error
classes
#KT-16484 Fixed
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
Pavel V. Talanov