Calling C++ constructors -- looking for feedback on my approach

Development Compiler
6

Getting back to this after working on something else.

I've looked at the details of what I would need to do, and I'd appreciate feedback on my plan.

I see two main issues to solve:

  • arrangeCXXConstructorCall() takes a CXXConstructorDecl, but SignatureExpansion::expandExternalSignatureTypes() doesn't have access to that.

    Indeed, as SignatureExpansion deals in function types, not function declarations, it shouldn't have access to the CXXConstructorDecl.

    Luckily, arrangeCXXConstructorCall() doesn't need very much from the CXXConstructorDecl. It really just wants the clang::FunctionProtoType (which I think we can get through SILFunctionType::getClangFunctionType()) and a clang::GlobalDecl, which it passes to CGCXXABI::HasReturn and CGCXXABI::hasMostDerivedReturn. Those two functions really just need the clang::Decl::Kind (which we could hardcode as Decl::Kind::CXXConstructor) and the clang::CXXCtorType (which I believe we could hardcode as Ctor_Complete). So if we change these functions in Clang, I think we should have everything we need to pass into arrangeCXXConstructorCall().

  • SignatureExpansion::expandExternalSignatureTypes() would need to know whether to call arrangeFreeFunctionCall(), arrangeCXXMethodCall() or arrangeCXXConstructorCall().

    There are two ways I can see to do this:

    • Try to infer from the SILFunctionType what we're calling. If the function takes a thin metatype and returns an object of the same type, it's probably a C++ constructor. If it takes a self parameter, it's probably a C++ method. Otherwise, it's a free function.

      This approach would not require any more far-reaching changes, but it arguably encodes too much knowledge about expected SIL signatures in expandExternalSignatureTypes().

    • Introduce two new SILFunctionTypeRepresentation cases: CXXMethod and CXXConstructor. This is cleaner, and the new cases are a nice parallel to the existing ObjCMethod case. However, there are a lot of places that switch over SILFunctionTypeRepresenation and would need to be extended, so I'd like to know whether people think this is the right approach before starting work on it.