Support reg_addr register class in s390x inline assembly
In s390x, `r0` cannot be used as an address register (it is evaluated as zero in an address context).
Therefore, currently, in assemblies involving memory accesses, `r0` must be [marked as clobbered](1a1155653a/src/arch/s390x.rs (L58)) or [explicitly used to a non-address](1a1155653a/src/arch/s390x.rs (L135)) or explicitly use an address register to prevent `r0` from being allocated to a register for the address.
This patch adds a register class for allocating general-purpose registers, except `r0`, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.)
This is identical to the `a` constraint in LLVM and GCC:
https://llvm.org/docs/LangRef.html#supported-constraint-code-list
> a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero).
https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
> a
> Address register (general purpose register except r0)
cc ``@uweigand``
r? ``@Amanieu``
custom mir: make it clear what the return block is
Custom MIR recently got support for specifying the "unwind action", so now there's two things coming after the actual call part of `Call` terminators. That's not very self-explaining so I propose we change the syntax to imitate keyword arguments:
```
Call(popped = Vec::pop(v), ReturnTo(drop), UnwindContinue())
```
Also fix some outdated docs and add some docs to `Call` and `Drop`.
Fix: Properly set vendor in i686-win7-windows-msvc target
In #118150 , setting the `vendor` field of the `i686-win7-windows-msvc` target was forgotten, preventing us from easily checking the target using `cfg(target_vendor)`.
With this PR, we set the target vendor to "win7".
coverage: Avoid a query stability hazard in `function_coverage_map`
When #118865 started enforcing the `rustc::potential_query_instability` lint in `rustc_codegen_llvm`, it added an exemption for this site, arguing that the entries are only used to create a list of filenames that is later sorted.
However, the list of entries also gets traversed when creating the function coverage records in LLVM IR, which may be sensitive to hash-based ordering.
This patch therefore changes `function_coverage_map` to use `FxIndexMap`, which should avoid hash-based instability by iterating in insertion order.
cc ``@Enselic``
Report I/O errors from rmeta encoding with emit_fatal
https://github.com/rust-lang/rust/issues/119456 reminded me that I never did systematic testing to provoke the out-of-disk ICEs so I grepped through a recent crater run (https://github.com/rust-lang/rust/pull/119440#issuecomment-1873393963) for more out-of-disk ICEs on current master and yep there's 2 in there.
So I finally cooked up a way to provoke for these crashes. I wrote a little `cdylib` crate that has a `#[no_mangle] pub extern "C" fn write` which occasionally reports `ENOSPC`, and prints a backtrace when it does.
<details><summary><strong>code for the dylib</strong></summary>
<p>
```rust
// cargo add libc rand backtrace
use rand::Rng;
#[no_mangle]
pub extern "C" fn write(
fd: libc::c_int,
buf: *const libc::c_void,
count: libc::size_t,
) -> libc::ssize_t {
if fd > 2 && rand::thread_rng().gen::<u8>() == 0 {
let mut count = 0;
backtrace::trace(|frame| {
backtrace::resolve_frame(frame, |symbol| {
if let Some(name) = symbol.name() {
if count > 3 {
eprintln!("{}", name);
}
}
count += 1;
});
true
});
unsafe {
*libc::__errno_location() = libc::ENOSPC;
}
return -1;
} else {
unsafe {
let res =
libc::syscall(libc::SYS_write, fd as usize, buf as usize, count as usize) as isize;
if res < 0 {
*libc::__errno_location() = -res as i32;
-1
} else {
res
}
}
}
}
```
</p>
</details>
Then `LD_PRELOAD` that dylib and repeatedly build a big project until it ICEs, such as with this:
```bash
while true; do
cargo clean
LD_PRELOAD=/home/ben/evil/target/release/libevil.so cargo +stage1 check 2> errors
if grep "thread 'rustc' panicked" errors; then
break
fi
done
```
My "big project" for testing was an otherwise-empty project with `cargo add axum`.
Before this PR, the above procedure finds a crash in between 1 and 15 minutes. With this PR, I have not found a crash in 30 minutes, and I'll be leaving this to run overnight (starting now). (A night has now passed, no crashes were found)
I believe the problem is that even though since https://github.com/rust-lang/rust/pull/117301 we correctly check `FileEncoder` for errors on all paths, we use `emit_err`, so there is a window of time between the call to `emit_err` and the full error reporting where rustc believes it has emitted a valid rmeta file and will permit Cargo to launch a build for a dependent crate. Changing these calls to `emit_fatal` closes that window.
I think there are a number of other cases where `emit_err` has been used instead of the more-correct `emit_fatal` such as e51e98dde6/compiler/rustc_codegen_ssa/src/back/write.rs (L542) but unlike rmeta encoding I am not aware of those cases of those causing problems.
r? ``@WaffleLapkin``
Update tracking issue of naked_functions
The original tracking issue #32408 was superseded by the new one #90957 (constrainted naked functions) and therefore is closed.
Query panic!() to useful diagnostic
Changes some more ICEs from bare panic!()s
Adds an `expect_job()` helper method as that is a moral equivalent of what was happening at the uses.
re:#118955
When #118865 started enforcing the `rustc::potential_query_instability` lint in
`rustc_codegen_llvm`, it added an exemption for this site, arguing that the
entries are only used to create a list of filenames that is later sorted.
However, the list of entries also gets traversed when creating the function
coverage records in LLVM IR, which may be sensitive to hash-based ordering.
This patch therefore changes `function_coverage_map` to use `FxIndexMap`, which
should avoid hash-based instability by iterating in insertion order.
rustc_lint: Enforce `rustc::potential_query_instability` lint
Stop allowing `rustc::potential_query_instability` on all of `rustc_lint` and instead allow it on a case-by-case basis if it is safe to do so. In this particular crate, all lints were safe to allow.
Part of https://github.com/rust-lang/rust/issues/84447 which is E-help-wanted.
Stop allowing `rustc::potential_query_instability` on all of
`rustc_lint` and instead allow it on a case-by-case basis if it is safe
to do so. In this particular crate, all lints were safe to allow.
Fix `<BoundConstness as Display>`
There was infinite recursion, which is not very good. I'm not sure what the best way to implement this is, I just did something that felt right.
r? `@fmease`
Move around the code responsible for decorating builtin diagnostics
This PR move the code responsible for decorating builtin diagnostics into a separate sub-module for ease of use and readability.
While my original intention was to also move the check-cfg unexpected logic in their own function I changed my mind after moving the match altogether. I can move those if desired.
Fixes https://github.com/rust-lang/rust/pull/119425#discussion_r1438446596
r? `@Nilstrieb`
Update to bitflags 2 in the compiler
This involves lots of breaking changes. There are two big changes that force changes. The first is that the bitflag types now don't automatically implement normal derive traits, so we need to derive them manually.
Additionally, bitflags now have a hidden inner type by default, which breaks our custom derives. The bitflags docs recommend using the impl form in these cases, which I did.
r? compiler
This involves lots of breaking changes. There are two big changes that
force changes. The first is that the bitflag types now don't
automatically implement normal derive traits, so we need to derive them
manually.
Additionally, bitflags now have a hidden inner type by default, which
breaks our custom derives. The bitflags docs recommend using the impl
form in these cases, which I did.
coverage: Prepare mappings separately from injecting statements
These two tasks historically needed to be interleaved, but after various recent changes (including #116046 and #116917) they can now be fully separated.
---
`@rustbot` label +A-code-coverage
These two tasks historically needed to be interleaved, but after various recent
changes (including #116046 and #116917) they can now be fully separated.
Fix invalid check-cfg Cargo feature diagnostic help
#118213 added specialized diagnostic for Cargo `feature` cfg. However when providing an empty `#[cfg(feature)]` condition the suggestion would suggest adding `feature` as a feature in `Cargo.toml` (wtf!).
This PR removes the invalid logic, which even brings a nice improvement.
```diff
--> $DIR/cargo-feature.rs:18:7
|
LL | #[cfg(feature)]
- | ^^^^^^^
+ | ^^^^^^^- help: specify a config value: `= "bitcode"`
|
= note: expected values for `feature` are: `bitcode`
- = help: consider defining `feature` as feature in `Cargo.toml`
```
The first commit add a test showing the bug and the second commit fixes the bug.
`@rustbot` label +F-check-cfg
