Sync rustc_codegen_cranelift
The main highlight of this sync is support for cross-compiling to Windows using MinGW. Native compilation with MinGW would also work I think, but using the MSVC toolchain is not yet supported as PE TLS is not yet implemented. Another nice improvement is that crate metadata is now loaded using mmap instead of by reading files. This improves compilation time a bit.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
update Miri, and also run test suite with mir-opt-level=4
In the Miri repo, we run the Miri test suite once with default flags and once with `-O -Zmir-opt-level=4`. This helps identify and document situations where MIR optimizations mask UB -- it is okay for that to happen, but it might be god to look into it when it does happen. Recently these tests failed fairly frequently as new MIR optimizations were added, and since we only run them on the Miri side, it is not even clear which rustc PR introduced the change. So I propose we also run these tests in the rustc repo, such that toolstate tracking will tell us the exact PR (or at least the rollup) that caused the change.
r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/83590
unaligned_references: align(N) fields in packed(N) structs are fine
This removes some false positives from the unaligned_references lint: in a `repr(packed(2))` struct, fields of alignment 2 (and less) are guaranteed to be properly aligned, so we do not have to consider them "disaligned".
linker: Use data execution prevention options by default when linker supports them
Do it in a centralized way in `link.rs` instead of individual target specs.
r? `@nagisa`
The tests issue-36710 and incr-prev-body-beyond-eof were changed in a
previous commit so that the correct target was passed to rustc
(previously rustc was building for the host not for the specific
target).
Since that change it turns out that these platforms never worked (they
only appeared to work because rustc was actually building for the host
architecture).
The wasm architectures fall over trying to build the C++ file in
issue-36710. They look for clang (which isn't installed in the
test-various docker container). If clang is installed, they can't find
a wasm c++ standard library to link to.
nvtptx64-nvidia-cuda fails in rustc saying it can't find std. The rust
platforms support page says that std is supported on cuda so this is
surprising.
dist-i586-gnu-i586-i686-musl can't find the C++ compiler. There is only
a musl-gcc and no musl-g++ in /musl-i586/bin/. The Docker image probably
needs tweaking.
When we cross compile, some things (and their documentation) are built
for the host (e.g. rustc), while others (and their documentation) are built
for the target. This generated documentation will have broken links
between documentation for different platforms e.g. between rustc and
cargo.
Resolves#78911
The target's linker was used but rustc wasn't told to build for that
target (instead defaulting to the host). This led to the host instead of
the target getting tested and to the linker getting inappropriate
arguments.
may not -> might not
may not -> might not
"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."
In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)
This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.
This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
Adjust documentation links for slice::make_ascii_*case
The documentation for the functions `slice::to_ascii_lowercase` and `slice::to_ascii_uppercase` contain the suggestion
> To lowercase the value in-place, use `make_ascii_lowercase`
however the link to the suggested method takes you to the page for `u8`, rather than the method of that name on the same page.
rustc_target: Avoid unwraps when adding linker flags
These `unwrap`s assume that some linker flags were already added by `*_base::opts()` methods, but that's doesn't necessarily remain the case when we are reducing the number of flags hardcoded in targets, as https://github.com/rust-lang/rust/pull/83587 shows.
r? `@nagisa`
Instruct LLVM that binary_search returns a valid index
This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this, not sure if it's the right thing to do (I didn't find anything on the dev guide), but it felt so.
- Add back various diagnostic methods on `Session`.
It seems unfortunate to duplicate these in so many places, but in the
meantime, making the API inconsistent between `Session` and `Diagnostic`
also seems unfortunate.
- Add back TyCtxtAt methods
These will hopefully be used in the near future.
- Add back `with_const`, it would need to be added soon after anyway.
- Add back `split()` and `get_mut()`, they're useful.
- Add back `HirIdVec`, with a comment that it will soon be used.
- Add back `*_region` functions, with a comment they may soon be used.
- Remove `-Z borrowck_stats` completely. It didn't do anything.
- Remove `make_nop` completely.
- Add back `current_loc`, which is used by an out-of-tree tool.
- Fix style nits
- Remove `AtomicCell` with `cfg(parallel_compiler)` for consistency.
Found with https://github.com/est31/warnalyzer.
Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
wants to use it in the future?
- Don't change rustc_serialize
I plan to scrap most of the json module in the near future (see
https://github.com/rust-lang/compiler-team/issues/418) and fixing the
tests needed more work than I expected.
TODO: check if any of the comments on the deleted code should be kept.
linker: Use `--as-needed` by default when linker supports it
Do it in a centralized way in `link.rs` instead of individual target specs.
Majority of relevant target specs were already passing it.
