Internal configurations targeting Darwin employ ThinLTO to
improve compiler performance, however using it on all executable
causes build time to increase with no matching benefit.
To reduce build times in such configurations, we allow some
ancillary targets to opt out of LLVM IR optimizations when linking
ThinLTO with ld64 (e.g. tools used for bootstrapping or debugging the
Swift compiler) -- this behaviour is opt in through a new flag
`--swift-tools-ld64-lto-codegen-only-for-supporting-targets`.
Addresses rdar://76702687
A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
The tool is currently hard-coded to find functions in the SwiftUI library that take parameters of type `(...) -> T` where `T: View` but where the parameter isn't annotated with `@ViewBuilder`. The long-term vision here, of course, is that this reads and interprets a script file, but that's quite a bit more work (especially to generate a million bindings to the AST). In the meantime, I think having a functional harness that people familiar with the C++ API can easily hack on to make their own tools is still pretty useful.
The harness does try to open a script file and lex the first token of it, because that's exactly as far as I got before deciding to hard-code the query I wanted. Since this input is otherwise ignored, you can just point the tool at any old `.swift` file (or just an empty file) and it'll be fine.
