Add support to the driver for CLI flags that select which CPU to target,
which CPU to tune performance for, and which CPU features to enable.
- `--target-cpu` selects the architecture of CPU to target, similar to
`-march` on x86. This combines `-march` with `armv*` strings and `-mcpu`
on Arm for specific CPU names. Similarly for RISC-V (if/when we support
and test it), etc. Notably, `--target-cpu=native` targets the current
native CPU.
- `--target-cpu-tune` maps to `-mtune`. This is expected to be rarely if
ever desirable, and I'm open to removing it, but if folks are relying on
this for performance I didn't want to hide the option.
- `--target-cpu-features` allows a "standard" (for LLVM) comma-separated
list of LLVM subtarget features, including `+feature` and `-feature`
syntax.
These flags, when provided, establish the default baseline for CPU
targeting and control how on-demand runtimes are built. They can be
changed or overridden by additional Clang flags when using
`--clang-arg`.
A critical part of this is building runtimes on demand using these
features. For that, we need to do some amount of canonicalization
(re-using Clang's canonicalization to ensure consistent behavior), and
extend the runtimes cache features to recognize these customizations.
Note that only the top-level Carbon flags impact runtimes, any
particular Clang arguments are only used by the specific compiles that
receive those arguments.
There is some nascent RISC-V support here, but it is incomplete and only
minimally tested. Still, it seemed better to record the parts we could
test than remove them.
Assisted-by: Antigravity with Gemini
If a test would still fail post-autoupdate due to either mismatched
`fail_` prefix or due to being NOAUTOUPDATE, the test is reported as `?`
instead of `.` in the incremental progress output, and a message is
listed after the progress output describing the problem. For example:
```console
Problems that require manual fixes:
- `toolchain/check/testdata/basics/zz_prefix_probe.carbon` split `bad_missing_prefix.carbon` failed; if failure is expected, add the `fail_` prefix.
- `toolchain/driver/testdata/fail_config.carbon` succeeded; if success is expected, remove the `fail_` prefix.
```
This change caused the `NOAUTOUPDATE` test
`toolchain/driver/testdata/fail_config.carbon` to fail, because when run
under autoupdate (or with `bazel run`), the install manifest would be
present, and the test is checking that it's not. Fixed by using the VFS
to look for the manifest, which then required fixing
toolchain/driver:driver_test to set up a real filesystem VFS so that it
*could* find the manifest.
With this change, there should no longer be a reason to manually run
file_test in addition to running autoupdate.
Assisted-by: Claude via Antigravity
Support multi-file compilation, and in particular imports of files from
the prelude, in `carbon language_server`.
In order to properly interface with `CompileDriver`, also switch over to
building a proper VFS from the documents we're given.
Assisted-by: Gemini via Antigravity
Mainly because "sorting_diagnostic_consumer" is legacy, since
`SortingDiagnosticConsumer` became `SortingConsumer`. Also better
reflecting contents of these files.
Where I'm not renaming, I'm less positive about dropping "diagnostics"
from "file_diagnostics" and "null_diagnostics" (which contain both a
consumer and emitter, and "null.h" seems like poor naming), so not doing
that here. Also "diagnostic.h" contains `struct Diagnostic`, so is a
decent fit.
Assisted-by: Google Antigravity with Gemini 3 Flash
This makes it easy to wire up build systems like Bazel that need to know
the actual include paths used. It also gives us a convenient place to
export any other information that build systems or integrations need,
and to get debugging info from users.
Most of the complexity is computing the Clang header search paths, but
I couldn't see a direct way to get closer to the source-of-truth than
this, and it doesn't seem _too_ unreasonable.
Depends on #6636 - start review at commit
[643fdab1](6637/commits/643fdab1)