Unfortunately, the same testdata is used in IDE, so we should change
testdata in compiler repo and this will affect IDE repo.
This commit is the cherry-pick of commits from IDE repo:
- 4310d730795a53a Fix UltraLightClassLoadingTestGenerated.testEnums():
check by Java file as ULC produces a different but better result
Yan Zhulanow 3/17/21, 8:57 AM
- fbe3c8ba0841f2d4 Disable comparison test for
UltraLightClassSanityTestGenerated.
testAnnotatedPropertyWithSites() Yan Zhulanow 3/18/21, 1:33 PM
- 8fc53027343b5b53 Ignore known (for ages) broken behaviour
of LC Vladimir Dolzhenko 3/19/21, 11:17 PM
All the other annotation classes has abstract modifier.
All nested interfaces has static modifiers.
This commit is not so important for compiler, but it is matter for IDE,
because when we load classes in IDE via
KtLightClassForDecompiledDeclaration -- there are Abstract and Static
on the Container class
Unfortunately, the world of native development is diverse,
and we can't generate one bitcode that is correct on every platform.
What is important to us is that AAPCS64 and Windows x64 extend
<32 bit arguments on callee side, so we can't use zext/sext args for them.
It is hard to run FileCheck tests over generated ObjC bridges because
they share the same name ("objc2kotlin"). To overcome this hurdle,
this commit introduces a compiler flag that appends function name to
"objc2_kotlin". This change might be useful for end-users, for example,
it makes stacktraces more readable. But it will require additional
testing and polishing which is out of the scope of this change.
(I messed up commit history and all changes had to be squashed. Sorry.)
The commit is originated from KT-48591. The root of the problem is
following: we unconditionally added sext to all value parameters of
imported functions. To fix this problem we have to pass zext/sext
depending on the parameter type.
To make things right and future-proof, we decided to refactor
a significant part of IR to bitcode translator: when generating callsite
compiler "looks" at callee and applies its attributes to the callsite.
There are several sources of attributes:
1. External LLVM functions from runtime: just copy-paste attributes.
2. Direct IR calls: infer attributes from the declaration.
3. Virtual calls: use available declaration, so almost the same as prev.
4. External declarations functions: manual labor!
Specifying attributes at all callsites (including Kotlin->Kotlin) makes
things uniform and a little easier to implement.
All in all, the delta is significant, but comprehensible. In some places
I managed to make it seamless by changing declaration type and its
usages types simultaneously. In others (ObjCExport), unfortunately,
things got a little messy.
#KT-48722 fixed
Ilya Goncharov