I’ve reconsidered and have now taken an approach that doesn’t require me to plumb the GlobalDecl through to SignatureExpansion. This seemed problematic for reasons discussed before: It breaks the idea that a Signature can be computed solely from a CanSILFunctionType, and we’d need to make sure the constructor doesn’t get called indirectly. Besides, computing the correct LLVM signature isn’t the only problem we have to solve; we also have to make sure we pass the right implicit arguments when we actually call the constructor.
Instead, I now do this:
- Give the constructor a SIL function type that make
SignatureExpansionproduce a best-effort guess at what the constructor signature should look like (namely, pass athispointer as the first argument and returnvoid). - If this assumption wasn’t correct, emit a thunk that adds any required implicit parameters and adjusts the return type if necessary. This thunk is
alwaysinline, so there is no runtime overhead. There is some compile-time overhead from having LLVM inline the thunk; if this turns out to be excessive, I’ll make a followup change to emit the correct callsite without a thunk in the case of direct calls.
The PR (Add support for calling C++ constructors by martinboehme · Pull Request #30630 · apple/swift · GitHub) is still marked “draft”, but this is only because it requires a change to land in Clang that allows the implicit constructor args to be retrieved. I think this is the right approach and consider the PR to be final in terms of what I’d like to merge, and I’d appreciate a review at this point.