Add `sync` option to `-Z threads` to force synchronization on one thread
This adds a `sync` option to `-Z threads` to force synchronization while still using one thread. This is useful to measure overhead of synchronization without the noise of additional threads.
Add a suite of ChunkedBitSet union/subtract/intersect test scenarios
While working on https://github.com/rust-lang/rust/pull/153754, I found that these code paths are under-tested.
core: drop unmapped ZSTs in array `map`
Fixes https://github.com/rust-lang/rust/issues/152211.
Alternative to rust-lang/rust#152220 and rust-lang/rust#152248.
This makes the `Drain` type use the same ZST-handling strategy as `slice::IterMut`, which stores the remaining length instead of a one-past-the-end pointer when the type is a ZST. I've also removed the const-generic `N` parameter from `Drain` to avoid unnecessary monomorphizations.
Experiment: Reborrow traits
With this PR we now have basic functional Reborrow and CoerceShared traits. The current limitations are:
1. Reborrowable types can only have one lifetime parameter, so as to avoid having to figure out and store in rmeta the information of which lifetimes weaken during reborrowing.
2. Reborrowing of `&mut` wrappers is working (though I've not tested generic wrappers like `Option<&mut T>` yet), but CoerceShared of `&mut` wrappers currently causes an ICE.
The remaining tasks to complete before I'd consider this PR mergeable are:
- [x] Fix ICE on CoerceShared. Unfortunately this might require dipping into rmeta.
- [x] Expand the tests to give a more complete view of the current state of the experiment.
Reborrow traits experiment: rust-lang/rust#145612
Co-authored by @dingxiangfei2009
Support `-Cpanic=unwind` on WASI targets
This commit is some minor updates/restructuring in a few locations with the end result being supporting `-Cpanic=unwind` on WASI targets. This continues to be off-by-default insofar as WASI targets default to `-Cpanic=abort`, meaning that actually using anything in this commit requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of `libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also updated here).
* The `unwind` crate here in this repository uses the `libunwind` module instead of the custom bare-metal wasm implementation of exceptions. This means that Rust uses the `_Unwind_*` symbols which allows it to interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument `-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of using the legacy exception handling proposal for WebAssembly. This has no effect by default because `panic=abort` is used on most targets. Emscripten is exempted from this as the Emscripten target is explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the `panic_unwind` crate which ended up requiring `-Wexceptions` from Wasmtime, so the test parts were updated and Wasmtime was updated in CI, too.
The net result of all of this is that this should not actually affect any WebAssembly target's default behavior. Optionally, though, WASI programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary to enable this support on wasm targets.
Finally, this ends up closing rust-lang/rust#154593 as well. The WASI targets are now defined to use `-lunwind` to implement unwinding. This means that the in-tree definition of `__cpp_exception` is no longer of concern and the definition is always sourced externally. If Rust is linked with other C/C++ code using WASI then these idioms are compatible with wasi-sdk, for example, to use that as a linker. The main caveat is that when using an external linker the `-fwasm-exceptions` argument needs to be passed to `clang` for it to be able to find the `libunwind.a` library to link against.
Closesrust-lang/rust#154593
This commit is some minor updates/restructuring in a few locations with
the end result being supporting `-Cpanic=unwind` on WASI targets. This
continues to be off-by-default insofar as WASI targets default to
`-Cpanic=abort`, meaning that actually using anything in this commit
requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of
`libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also
updated here).
* The `unwind` crate here in this repository uses the `libunwind` module
instead of the custom bare-metal wasm implementation of exceptions.
This means that Rust uses the `_Unwind_*` symbols which allows it to
interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument
`-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of
using the legacy exception handling proposal for WebAssembly. This has
no effect by default because `panic=abort` is used on most targets.
Emscripten is exempted from this as the Emscripten target is
explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the
`panic_unwind` crate which ended up requiring `-Wexceptions` from
Wasmtime, so the test parts were updated and Wasmtime was updated in
CI, too.
The net result of all of this is that this should not actually affect
any WebAssembly target's default behavior. Optionally, though, WASI
programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary
to enable this support on wasm targets.
Finally, this ends up closing 154593 as well. The WASI targets are now
defined to use `-lunwind` to implement unwinding. This means that the
in-tree definition of `__cpp_exception` is no longer of concern and the
definition is always sourced externally. If Rust is linked with other
C/C++ code using WASI then these idioms are compatible with wasi-sdk,
for example, to use that as a linker. The main caveat is that when using
an external linker the `-fwasm-exceptions` argument needs to be passed
to `clang` for it to be able to find the `libunwind.a` library to link
against.
Closes 154593
cg_clif: Don't show verbose run-make cmd output for passing tests
Uses `--verbose-run-make-subprocess-output=false` added in rust-lang/rust#154587 to suppress verbose cmd dump for passing `run-make` tests.
Closesrust-lang/rust#154069.
Add better default spans for the `Ty` impl of `QueryKey`
This add default spans for `Ty` in its implementation of `QueryKey`. This is useful so we can get spans for the `layout_of` query which shows up in cycle errors.
CFI: Fix LTO for `#![no_builtins]` crates with CFI
Fixes LTO for `#![no_builtins]` crates with CFI enabled by using rustc's `EmitObj::Bitcode` path (and emitting LLVM bitcode in the `.o` for linker-based LTO).
It also adds tests that verify that the examples in [rust-cfi-examples](https://github.com/rcvalle/rust-cfi-examples) build and run with `-Zbuild-std` to prevent other future regressions.
Add `keepalive`, `set_keepalive` to `TcpStream` implementations
## What
The current implementation of `TcpStream` does not expose `SO_KEEPALIVE`: rust-lang/rust#69774
## Why
It seems the reason this has not yet been implemented is because the initial implementation went as far as to take the keepalive interval as a parameter. However, Windows does not directly expose these intervals for reading, causing there to be some debate about the shape of the API (see the discussion of this [here](https://github.com/rust-lang/rust/pull/31945#issuecomment-189784913)).
## How
I am proposing that this API is enabled with a `bool` parameter to align with the implementation in both Windows and Unix, as it is the least common denominator between the two of them. With regards to the call to `setsockopt`, [Windows expects a disable/enable](https://learn.microsoft.com/en-us/windows/win32/winsock/so-keepalive), and [Unix does as well](https://man7.org/linux/man-pages/man7/socket.7.html).
The extra configuration for Unix that allows the interval to be tweaked could be done through an additional API perhaps, but I don't think that's stopping us from exposing the switch to at least enable the behavior with the OS defaults.
Tracking issue: rust-lang/rust#155889
lint ImproperCTypes: refactor linting architecture (part 2)
This is the second PR in an effort to split https://github.com/rust-lang/rust/pull/134697 (refactor plus overhaul of the ImproperCTypes family of lints) into individually-mergeable parts.
Contains the changes of the first PR, and splits the core type checking function into several bits, each focused on a specific aspect of FFI-safety.
Some logic which was outside of said core function was also moved into the new functions.
Superset of: rust-lang/rust#146271
Document wasi-sdk minimum versions for WASI targets
This commit updates the documentation for WASI targets in the rustc book to mention a minimum version of wasi-sdk that's required.
Closesrust-lang/rust#155971
compiletest: prevent directives from having multiple revisions
Right now, a compiletest directive like `//@ [foo,bar] compile-flags: -Z hello` is accepted. While it looks similar to a `//[foo,bar]` error annotation matching multiple revisions, it will instead model a directive for a single revision named `foo,bar` and not for two revisions. Slightly inconsistent/confusing.
I don't know that it's common enough to make bigger changes to support it fully (`miri`'s test harness seems to support that use-case), but since I hit that today, this PR prevents that case for now. Otherwise, I think we'd have to turn all uses of `line_directive` as possibly creating multiple line directives, one per revision, etc.
Such a directive will now yield an error, with a best-effort suggestion to split it into multiple single-revision directives:
```
multiple revisions aren't supported yet in `//@ [foo,bar] compile-flags: -Z hello`, split them like
//@ [foo]: compile-flags: -Z hello
//@ [bar]: compile-flags: -Z hello
```
Ralf Jung