Add a new driver tool/mode to print the synthesized Swift interface for a module. #76872
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…or a module. This mode is similar to `swift-symbolgraph-extract`; it takes a subset of compiler flags to configure the invocation for module loading, as well as a module name whose contents should be extracted. It does not take any other input files. The output is a single text file specified by `-o` (or `stdout` if not specified). While the most common use case for this would be viewing the synthesized Swift interface for a Clang module, since the implementation simply calls `swift::ide::printModuleInterface` under the hood, it's usable for any module that Swift can import. Thus, it could also be used to view a synthesized textual representation of, say, a compiled `.swiftmodule`. One could imagine that in the future, we might add more flags to `swift-synthesize-interface` to modify various `PrintOptions` used when generating the output, if we think those would be useful.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This mode is similar to
swift-symbolgraph-extract; it takes a subset of compiler flags to configure the invocation for module loading, as well as a module name whose contents should be extracted. It does not take any other input files. The output is a single text file specified by-o(orstdoutif not specified).While the most common use case for this would be viewing the synthesized Swift interface for a Clang module, since the implementation simply calls
swift::ide::printModuleInterfaceunder the hood, it's usable for any module that Swift can import. Thus, it could also be used to view a synthesized textual representation of, say, a compiled.swiftmodule.One could imagine that in the future, we might add more flags to
swift-synthesize-interfaceto modify variousPrintOptionsused when generating the output, if we think those would be useful.Q: Why not use SourceKit?
SourceKit is great for interactive/IDE experiences, but getting the invocation correct can still be tricky due to subtle differences between SourceKit and the compiler (what the current working directory is, differences between raw vs. Mach-O format .pcm files, convenience, etc.).
So, I'm proposing that we just add a regular compiler invocation that can do this as well. When using a build system like Bazel that builds with explicit modules for C dependencies, it would be trivial to create extra actions that invoke the compiler in this mode and make those synthesized interfaces available to the user to browse. It would also be extremely convenient when debugging what an imported interface looks like if we're working in an environment where Xcode/SourceKit are not convenient to access.