To prevent binary-compatibility-validator from reporting it as a public
API; that happens because the signature is different after the
gradle-shadow-plugin is applied
Class.getMethod does not return protected methods from super class, so
we invoke getDeclaredMethod on each super class manually instead
#KT-18480 Fixed
The previous condition that checked if we'd skipped any optional
parameters didn't work when number of parameters > 32 because the number
of bit masks in that case was more than one
#KT-18404 Fixed
- Move the following from 'deserialization' to 'descriptors':
NotFoundClasses.kt
AdditionalClassPartsProvider.kt
ClassDescriptorFactory.kt
PlatformDependentDeclarationFilter.kt
findClassInModule.kt
- Move the following form 'descriptors' to 'deserialization':
BuiltInSerializerProtocol.kt
builtInsPackageFragmentProvider.kt
- Extract a marker interface from BuiltInsPackageFragment and move its
implementation to 'deserialization'
- Change the type of parameters in PlatformDependentDeclarationFilter
and AdditionalClassPartsProvider to ClassDescriptor
This will help in getting rid of the circular dependency of
'descriptors' <-> 'deserialization'
To prevent tests from altering outcomes of the subsequent tests.
Also expose the clearCaches method (in the internal class
ReflectionFactoryImpl) so that it can be used in other places in similar
circumstances
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
These two functions are supposed to fix an inconvenience in the design of
KProperty{1,2}.getDelegate for extension properties, where you have to pass an
instance of the extension receiver which is going to be completely ignored
#KT-8384 Fixed
Inline functions with reified type parameters are generated as private (see
AsmUtil.specialCaseVisibility), so we should treat them as "declared" in
reflection to look them up via getDeclaredMethod, not getMethod
#KT-14721 Fixed
This is a way for future compilers to cause previous compilers to report
diagnostics on usages of some declarations. Diagnostic can have a message
(and/or error code), level (error, warning, or completely hide the declaration
from the resolution), and Kotlin version, since which the diagnostic should no
longer be reported
Alexander Udalov