[interop] add an option to emit C++ header interface for a module #40923
Conversation
|
@swift-ci please smoke test |
|
Also, driver support for this option will be added in a follow-up patch too. |
| @@ -0,0 +1,54 @@ | |||
| // RUN: %empty-directory(%t) | |||
There was a problem hiding this comment.
Does it make sense to put this in Interop? Like test/Interop/Swift or something?
There was a problem hiding this comment.
Hmm, not sure. I think something like test/Interop/Swift doesn't make the most sense as it implies Swift is interoperating with itself. I think sticking to PrintAsCxx might make more sense.
| @@ -0,0 +1,54 @@ | |||
| // RUN: %empty-directory(%t) | |||
| // RUN: %target-swift-frontend(mock-sdk: %clang-importer-sdk) %s -typecheck -emit-cxx-header-path %t/empty.h | |||
There was a problem hiding this comment.
Nit: do you need -typecheck? Can this just be %target-swift-frontend -emit-cxx-header-path %t/empty.h?
There was a problem hiding this comment.
Yes, as the default mode doesn't type check and in the default mode we get this error as per canActionEmitClangHeader:
<unknown>:0: error: this mode does not support emitting C++ headers
|
@swift-ci please test |
| /// | ||
| /// \returns true if there were any errors | ||
| /// | ||
| /// \see swift::printAsCxx |
There was a problem hiding this comment.
Nit: that function is spelled swift::printAsCXX with capital XX :)
There was a problem hiding this comment.
Good catch, I'll fix it up in the next patch.
| @@ -578,6 +587,7 @@ createFromTypeToPathMap(const TypeToPathMap *map) { | |||
| return paths; | |||
| const std::pair<file_types::ID, std::string &> typesAndStrings[] = { | |||
| {file_types::TY_ObjCHeader, paths.ObjCHeaderOutputPath}, | |||
| {file_types::TY_ObjCHeader, paths.CxxHeaderOutputPath}, | |||
There was a problem hiding this comment.
This is a problem, because we have two different outputs associated with the same entry in the output file map, so we'll end up writing both the ObjC and C++ header to the same place. I've fixed the issue via #41015, but I think we should reconsider having separate ObjC vs. C++ generated headers. It's a mess for the build system, and what would we do about Objective-C++? Instead, I think we should generate a single header that uses #ifdefs to appropriately compile as C/ObjC/C++/ObjC++.
There was a problem hiding this comment.
Hi Doug, thanks for fixing this, and sorry about the breakage. I'm not sure if we would like to generate a single header, instead we actually would prefer to generate multiple C++ headers as they will be target-specific, one per target, and then have the build system create a unified C++ header one from them. Do you think that would be a reasonable idea, and should we even support path map in that case? Also, I don't believe we want to emit Objective-C++ headers, as that would be ambiguous - we would either want to emit Objective-C or C++, and then the programmer can import their preferred interface into Objective-C++ as desired.
This is an initial patch to start adding support for emitting C++ header interfaces for a module. It adds two option flags -
-emit-cxx-headerand-emit-cxx-header-path, similar to what exists for Objective-C headers. The added flag calls into a newprintAsCxxfunction, which doesn't print out the module contents yet, but will do so in the future. ThePrintAsObjClibrary will be renamed toPrintAsClangin a follow-up PR.