Make offset_of field parsing use metavariable which handles any spacing
As discussed at and around comments https://github.com/rust-lang/rust/issues/106655#issuecomment-1793485081 and https://github.com/rust-lang/rust/issues/106655#issuecomment-1793774183, the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`.
They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca)
```rust
macro_rules! off {
($a:expr) => {
offset_of!(m::S, 0. $a)
}
}
```
This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above.
This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC.
Tracking issue for offset_of: #106655
``@rustbot`` label F-offset_of
``@est31``
Remove libtest's dylib
libtest.so is only used by rustdoc, and tests seem to pass locally with this change. I suppose if this is broken, the only way to find out is to make a PR.
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`.
Switch from using `//~ERROR` annotations with `--error-format` to `error-pattern`
Fixes#118752
As noticed by ```@jyn514``` while working on a patch, tests failed due to `//~ERROR` annotations used in combination with the older `--error-format` which is now `error-pattern`.
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".
Update `thread_local` examples to use `local_key_cell_methods`
`local_key_cell_methods` has been stable for a while and provides a much less clunky way to interface with thread-local
Additionaly add context to the documentation about why types with interior mutability are needed.
r? libs
llvm: Allow `noundef` in codegen tests
LLVM 18 will automatically infer `noundef` in some situations. Adjust codegen tests to accept this.
See llvm/llvm-project#76553 for why `noundef` is being generated now.
``@rustbot`` label:+llvm-main
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 books
## rust-lang/reference
1 commits in f9f5b5babd95515e7028c32d6ca4d9790f64c146..3565c7978cfc9662f5963b135690ff9cbbfa0318
2023-12-29 21:01:19 UTC to 2023-12-29 21:01:19 UTC
- Use proper footnote for number literals `_` separator note (rust-lang/reference#1444)
## rust-lang/rust-by-example
1 commits in 4c2b24ff9d9cf19f2fcff799a3a49b9a2c50ae8e..c0be6299e52e4164c30ba6f41bd0ad0aaee64972
2023-12-21 15:22:11 UTC to 2023-12-21 15:22:11 UTC
- point to raw indentifiers, talking about fields (rust-lang/rust-by-example#1789)
## rust-lang/rustc-dev-guide
5 commits in 0610665a8687b1b0aa037917a1598b9f2a21e3ef..d13e85152a977cd0bcaf583cf5f49e86225697de
2023-12-30 09:58:25 UTC to 2023-12-19 10:02:34 UTC
- Prominently mention `profiler = true` on the coverage page (rust-lang/rustc-dev-guide#1844)
- Add a description of `unpretty=hir` to the HIR docs (rust-lang/rustc-dev-guide#1842)
- Fix typo in unsize docs (rust-lang/rustc-dev-guide#1843)
- Suggest `gcc_multi` to make `mir_opts` run on nixos (rust-lang/rustc-dev-guide#1841)
- bootstrapping: Clarify that stage0 std code is not executed to produce stage1 compiler (rust-lang/rustc-dev-guide#1840)
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.
rc: Take *const T in is_dangling
It is not important which one is used since `is_dangling` does not access memory, but `*const` removes the needs of `*const T` -> `*mut T` casts in `from_raw_in`.
Document that File does not buffer reads/writes
...and refer to `BufReader`/`BufWriter`.
This is a common source of efficiency issues in Rust programs written naively. Including this information with the `File` docs, and adding a link to the wrapper types, will help discoverability.
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
Temporarily disable M1 runners on GitHub Actions
This commit temporarily reverts the addition of M1 runners on GitHub Actions to work around a billing issue related to their beta.
The runners for `dist-aarch64-apple` were originally changed in 821b03d767, and the `aarch64-apple` job was added in 6909992501.
This commit temporarily reverts the addition of M1 runners on GitHub
Actions to work around a billing issue related to their beta. It also
removes the `aarch64-apple` job, which was only added after the addition
of M1 runners. Since it has never been tested on the prior hardware, we
are skipping the tests to reduce the risk of build failures.
`local_key_cell_methods` has been stable for a while and provides a much less
clunky way to interface with thread-local variables.
Additionaly add context to the documentation about why types with interior
mutability are needed.
LLVM 18 will automatically infer `noundef` in some situations.
Adjust codegen tests to accept this.
See llvm/llvm-project#76553 for why `noundef` is being generated now.
