The main problem here is that moduleName that is being passed to KPackageImpl
is useless: as can be seen in
ClosureCodegen.generateCallableReferenceDeclarationContainer, the name of the
current module is always written to the class file for a callable reference,
not the name of the module of the referenced declaration. This resulted in
reflection not loading the correct .kotlin_module file and subsequently not
finding the required file facade for a top-level function.
The commit does not fix the issue with the incorrect module name written in the
back-end, but workarounds it. It turns out, reflection can figure out the name
of the module of the referenced declaration itself by parsing the header from
the given java.lang.Class object for a single-file/multi-file package facade
and extract the package_module_name protobuf extension. Similar code was
already there in Member.getKPackage() in ReflectJvmMapping.kt but it did not
support multi-file classes, of which there are a lot in the standard library;
this is now supported
#KT-12630 Fixed
#KT-14731 Fixed
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
Since now `suspend (Int) -> String` will be serialized as `(Int, Continuation<String>) -> Any?` + suspend flag.
Before this change such type serialized like this: Function2<Int, String> + suspend flag. And yes, type `Function2<Int, String>` isn't correct, because Function2 expect 3 type arguments.
We have special logic for this case and we deserialize such error-written types correctly.
(cherry picked from commit 3518cbe)
For sdkModule we create builtIns with default language feature settings.
Also when we create sdkModuleResolverProvider we create builtIns cache.
Then for every other module we get builtIns cached by value isAdditionalBuiltInsFeatureSupported.
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
Inferred type of receiver of orElse is Optional<T & Any>
Generic descriptor is orElse(E!): E!
Substituted descriptor is orElse(T): T , and that is the problem.
Seems that E! => (T & Any)! gets expanded to just T or T & Any , however it should be expanded to
(T & Any) .. (T & Any)? => T & Any .. T & Any
T & Any is NotNullTypeParameter(T)
The problem is that (T & Any)? is expanded to T & Any,
that is seems to be wrong.
#KT-15236 Fixed
- 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 is needed because 1.1.2 binaries are considered pre-release (see
DeserializedDescriptorResolver), so it wasn't possible to compile
non-pre-release binaries with -language-version 1.0
The -Xskip-metadata-version-check command line argument is supposed to be used
to avoid getting errors only; the side effect that it also caused compiler to
write the pre-release flag to binaries was a mistake and is fixed now
We made it because of non-stable name resolution when project is multi platform. For such projects in platform module we have two classifiers with the same name, but impl class or type alias should win!
Metadata version is 1.1.2 since the start of Kotlin 1.1 EAP. Because the
pre-release flag was not written to class files compiled with 1.1 EAP, there's
no other way to figure out that they're pre-release except than to look at the
metadata version. This assumes that the version will be advanced to 1.1.3 once
Kotlin 1.1 is released
Catch all exceptions when deserializing metadata with an incompatible version
to prevent the compiler from failing on discovering incompatible classes on the
classpath. Note that this is not the perfect solution: any invariant may be
broken in the incompatible metadata and it may result in a later exception
Similarly to pre-release classes, load metadata for the class anyway and allow
the resolution to select it as the result and prohibit its usage in the end
with the special diagnostic reported in MissingDependencyClassChecker
Alexander Udalov