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
currently some old backend reporting schemes are used in IR backend that
rely on the PSI alement passing. This conflicts with updated generic
diagnostic infrastructure that is shared between FIR and IR backends.
As soon as such places will be abstracted out and the IR will be
completely switched to the new diagnostic infrastructure, this and
similar changes could be reverted.
David Saff