A flag for dumping the arguments being passed to the compiler

When migrating Swift code between build systems, it's helpful to see how the actual compilation is being changed and what the default arguments are for each swiftc invocation. To that end, it'd be great to dump a canonical list of all the arguments that may affect compilation. For example, if the swiftc invocation ends in -Onone -Osize, it would resolve that to -Osize. Or if no optimization argument was included, it would show what the default optimization level is. This behavior would be similar to clang's cc1 -compiler-options-dump flag.

1 Like

You can get this by passing -### to swiftc. It'll print command lines for all of the frontend jobs that the driver scheduled.


This is a nice step forward, thank you. The one remaining issue that I can see is defaults. If the original command omits the -O*, meaning its optimization level will be the default, then -### won't have any -O* either, even though it has implicitly picked the default.

clang's -compiler-options-dump does flag normalization? Hmm. I'm looking at the output of clang -O1 -O2 -Xclang -compiler-options-dump -E tmp.c and I see a JSON blob with two keys:

{ "features": [ ... ], "extensions": [ ... ] }

There's no mention of optimization levels here.

What you're asking for seems like a tricky thing to do in the general case because of dependencies. For example, Clang's -ffast-math implies a bunch of other flags and also the preprocessor definition __FAST_MATH__... Not saying it's impossible, but it'd probably be much easier to hack a script which takes input from -###, sorts and adds defaults for important things that you care about (like optimization level) and diff that, exchanging 100% fidelity for something that's quick to implement.

1 Like

Yes, clang's compiler-options-dump is not a complete version of this solution, but I think it's in the ballpark. Anyways, even just for myself, it would take some time to write the script and to determine what the default values for all the settings are since they don't always seem documented. I also want to raise this not just for myself but because I imagine a lot of people moving around build systems face this issue. I've seen it at two large companies already.

FYI the facilities for resolving these do appear to exist somewhere already since swiftinterface files have the resolved values:

% swiftc foo.swift -emit-module-interface-path foo.swiftinterface -c -enable-library-evolution -O -Onone
% cat foo.swiftinterface
// swift-module-flags: -target x86_64-apple-darwin19.5.0 -enable-objc-interop -enable-library-evolution -Onone -module-name foo
1 Like

Good spot, thanks! I've filed a JIRA to create this flag with some implementation hints and concerns: https://bugs.swift.org/browse/SR-13031. While I don't intend to work on it, I'd be happy to help if @michaeleisel or someone else is interested in implementing this. It's a bit more involved than a typical StarterBug but hopefully not too complicated. :slightly_smiling_face:

Terms of Service

Privacy Policy

Cookie Policy