Currently when linking an artifact rustc will only conditionally call
the `Linker::export_symbols` function, but this causes issues on some
targets, like WebAssembly, where it means that executable outputs will
not have the same symbols exported that cdylib outputs have. This commit
sinks the conditional call to `export_symbols` inside the various
implementations of the function that still need it, and otherwise the
wasm linker is configured to always pass through symbol visibility
lists.
The commit moves metadata writing from `link_binary` to
`encode_metadata` (and renames the latter as
`encode_and_write_metadata`). This is at the very start of code
generation.
To implement pipelining, Cargo needs to know when metadata generation is
finished. This commit adds code to do that. Unfortunately, metadata file
writing currently occurs very late during compilation, so pipelining
won't produce a speed-up. Moving metadata file writing earlier will be a
follow-up.
The change involves splitting the existing `Emitter::emit` method in
two: `Emitter::emit_diagnostic` and `Emitter::emit_directive`.
The JSON directives look like this:
```
{"directive":"metadata file written: liba.rmeta"}
```
The functionality is behind the `-Z emit-directives` option, and also
requires `--error-format=json`.
Clean up handling of `-Z pgo-gen` commandline option.
This PR adapts the `-Z pgo-gen` flag to how Clang and GCC handle the corresponding `-fprofile-generate` flag. In particular, the flag now optionally takes a directory to place the profiling data in and allows to omit the argument (instead of having to pass an empty string).
Use informational target machine for metadata
Since there is nothing to optimise there...
Should fix#58323 but haven’t tested locally.
r? @michaelwoerister
rustc: Allow using `clang` for wasm32 targets
This commit adds support code for using `clang` directly to link the
wasm32-unknown-unknown target. Currently the target is only really
configured to link with LLD directly, but this ensures that `clang` can
be configured as well.
While not immediately useful in the near term it's likely that more
wasm32 targets will pop up over time with Clang's new native support for
WebAssembly in the 8.0.0 release. Getting support into rustc early
should make it easier to experiment with these targets and try out
various changes here and there.
rustc: Update linker flavor inference from filename
This commit fixes what is believed to be a preexisting bug in the linker
flavor inference and additionally adds a new features. Previously if the
linker didn't end in `exe` the entire file name was compared to infer
the linker's flavor. This commit fixes the code to instead
unconditionally inspect `file_stem()` which is the relevant part we're
looking at to figure out what the linker flavor is.
Additionally this commit now also adds recognition of `clang` and clang
wrappers that end in `-clang` (which look like gcc wrappers). This
should allow clang-specific wrappers to get correctly inferred to the
`Gcc` linker flavor rather than the default linker flavor configured for
a target.
This commit adds support code for using `clang` directly to link the
wasm32-unknown-unknown target. Currently the target is only really
configured to link with LLD directly, but this ensures that `clang` can
be configured as well.
While not immediately useful in the near term it's likely that more
wasm32 targets will pop up over time with Clang's new native support for
WebAssembly in the 8.0.0 release. Getting support into rustc early
should make it easier to experiment with these targets and try out
various changes here and there.
This commit fixes what is believed to be a preexisting bug in the linker
flavor inference and additionally adds a new features. Previously if the
linker didn't end in `exe` the entire file name was compared to infer
the linker's flavor. This commit fixes the code to instead
unconditionally inspect `file_stem()` which is the relevant part we're
looking at to figure out what the linker flavor is.
Additionally this commit now also adds recognition of `clang` and clang
wrappers that end in `-clang` (which look like gcc wrappers). This
should allow clang-specific wrappers to get correctly inferred to the
`Gcc` linker flavor rather than the default linker flavor configured for
a target.
Teach `-Z treat-err-as-bug` to take a number of errors to emit
`-Z treat-err-as-bug` will cause `rustc` to panic after the first error is reported, like previously. `-Z treat-err-as-bug=2` will cause `rustc` to panic after 2 errors have been reported.
Fix#58983.
`-Z treat-err-as-bug=0` will cause `rustc` to panic after the first
error is reported. `-Z treat-err-as-bug=2` will cause `rustc` to
panic after 3 errors have been reported.
rustc: Implement incremental "fat" LTO
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
cc #57968
cc rust-lang/cargo#6643
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
cc #57968
cc rust-lang/cargo#6643
