Generate swiftinterface files next to the stdlib swiftmodules #18973
Conversation
The OutputInfo, ToolChain, and Triple can all be retrieved from the Compilation, so now that we're passing one of those around we don't need to pass the others explicitly. No functionality change.
This will eventually become plain old -emit-interface, but we don't want people to be using it just yet. This is just for testing.
We're not using them for anything yet, but this will exercise -emit-interface while we're working on it and make sure that it doesn't crash when processing complex code like the standard library.
jrose-apple
requested review from
graydon,
davidungar,
gottesmm,
harlanhaskins and
Rostepher
|
@swift-ci Please test |
| } else if (Args.hasArg(options::OPT_emit_objc_header, | ||
| options::OPT_emit_objc_header_path, | ||
| options::OPT_experimental_emit_interface) && | ||
| OI.CompilerMode != OutputInfo::Mode::SingleCompile) { |
There was a problem hiding this comment.
Why the additional OI.CompilerMode != OutputInfo::Mode::SingleCompile condition here?
There was a problem hiding this comment.
These are outputs that need whole-module knowledge in some form, but don't actually need a swiftmodule to be generated. So if you're compiling with WMO and don't need a swiftmodule for whatever reason, you won't spend time generating one anymore. I don't really expect this to come up in practice, though.
| case OutputInfo::Mode::StandardCompile: | ||
| case OutputInfo::Mode::BatchModeCompile: | ||
| if (!isa<MergeModuleJobAction>(JA)) | ||
| return; |
There was a problem hiding this comment.
I'm not super keen on this pattern of silently not-doing what the function's name says it does, when not matching certain conditions not-expressed in the signature; it means that reading the caller, one's assumption that "a textual interface output name has been set" is not correct. But I know it matches other filename-choosing functions. Do you feel like there's an easy way to tidy it up a bit?
There was a problem hiding this comment.
Yeah, all of these split their conditions between the callers and the first few lines of the function, which is a little funny. Maybe they should all be addFooBarIfNeeded like the frontend helper functions instead.
I was justifying continuing this pattern by saying "nil is a valid 'choice'", but if you want I can put more thought into that.
Add a driver option -experimental-emit-interface for textual interfaces, then hook it up in CMake. We're not using this for anything yet, but this will exercise -emit-interface while we're working on it and make sure that it doesn't crash when processing complex code like the standard library.
Looking for review from David or Graydon on the Driver changes and Ross or Michael for the CMake.