Feature Request: Experimental feature to leverage `clang`'s `--config` feature to mitigate "Argument list too long" issue in large codebases

Wanted to start a discussion to understand if this is desired and if there are any flaws I'm missing.

In a large iOS codebase one of our targets hits a "Argument list too long" failure when building in Xcode due to a very large list of compiler flags being set in the OTHER_SWIFT_FLAGS build setting. While we work to simplify the build graph and reduce the number of flags needed to compile such target we might have to consider alternative ways to mitigate the issue.

After seeing this discussion in the Bazel slack decided to try to come up with a PoC minimal enough so I can test things in Xcode. Here's a draft branch:

thiago/clang-config-in-other-swift-flags

• This effectively sends all clang flags to a clang.params file and sets -Xcc --config=path/to/foo.clang.params in OTHER_SWIFT_FLAGS
• The key changes are in ProcessSwiftArgs.swift, the rest is just there to generate the file with Bazel and make bazel test //... pass in the repo

I've been experimenting with this commit internally and so far most basic interactions in Xcode seem to work fine and I'm able to build big targets without hitting the "Argument list too long" issue.

That said, main concerns I'd appreciate feedback on:

• Is this desired by others and worth adding as an experimental feature?
• Would indexing work reliably with this approach?
• Would LLDB work reliably with this approach?
• Would the overhead introduced to generate files be acceptable?
• Any hard blocker I'm missing?

Start with the proposed changes in ProcessSwiftArgs.swift and compare the draft branch linked in the issue with main. Run bazel test //... and inspect how the generated clang.params file is passed through OTHER_SWIFT_FLAGS. Done means establishing whether the experimental approach works reliably with Xcode indexing and LLDB and whether its file-generation overhead is acceptable.