Method `isBuiltIn` may not work correctly as built-ins are becoming
more and more like a usual dependency. Also behaviour of this method is
depend on the target platform.
The problem was that for property getter 'context.getContextDescriptor()'
references the containing property, while 'context.getFunctionDescriptor()'
the accessor itself
#KT-15594 Fixed
Usually, we have only CapturedType with such constructor.
We should prevent creation such types in the future (KT-16147).
Also added test for KT-14740 where this problem originally appears.
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
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
Alexander Udalov