[CI] Upload average CPU utilization of CI jobs to DataDog
This PR adds a new CI step that uploads the average CPU utilization of the current GH job to Datadog. I want to add more metrics in follow-up PRs.
r? `@jdno`
try-job: dist-i686-msvc
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
Update helper docs display disable option
Updated helper docs via configure.py to make it clearer that users can control options with enable and disable
Fixing issue #129146
A couple of fixes for dataflow graphviz dumps
A couple of trivial drive-by fixes to issues I noticed while debugging my buggy borrowck code:
One is a fix of the `-Zdump-mir-dataflow` file extensions, the dataflow graphviz files are currently dumped as `..dot`.
<details>
```console
-rw-rw-r-- 1 lqd lqd 13051 Oct 1 23:21 mir_dump/issue_47680.main.-------.borrows.borrowck..dot
-rw-rw-r-- 1 lqd lqd 13383 Oct 1 23:21 mir_dump/issue_47680.main.-------.ever_init.borrowck..dot
-rw-rw-r-- 1 lqd lqd 13591 Oct 1 23:21 mir_dump/issue_47680.main.-------.maybe_init.borrowck..dot
-rw-rw-r-- 1 lqd lqd 9257 Oct 1 23:21 mir_dump/issue_47680.main.-------.maybe_init.elaborate_drops..dot
-rw-rw-r-- 1 lqd lqd 14086 Oct 1 23:21 mir_dump/issue_47680.main.-------.maybe_uninit.borrowck..dot
-rw-rw-r-- 1 lqd lqd 9257 Oct 1 23:21 mir_dump/issue_47680.main.-------.maybe_uninit.elaborate_drops..dot
```
<summary>Some examples on nightly</summary>
</details>
And the other is for the specific `Borrows` dataflow analysis, whose domain is loans but shows locations when dumped (the location where the loan is introduced). It's not a huge deal but we didn't even print these locations in MIR dumps, and in general cross-referencing loan data (like loan liveness) is more annoying without this change.
<details>
<summary>Here's how it'll look in case inquisitive minds want to know</summary>
</details>
The visualization state diff display is still suboptimal in loops for some of the effects escaping a block, e.g. a gen that's not dominated/postdominated by a kill will not show up in statement diffs. (This happens in the previous screenshot, there's no `+bw1` anywhere). We can fix that in the future.
Revert #131060 "Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags"
In [#131059] we found out that `-Zon-broken-pipe=kill` is actually **load-bearing**[^1] for
(at least) `rustc` and `rustdoc` to have the kill-process-on-broken-pipe behavior, e.g. `rustc
--print=sysroot | false` will ICE and `rustdoc --print=sysroot | false` will panic on a broken pipe.
This PR reverts 5a7058c5a5 (reverts PR #131060) in favor of a future
fix to *unconditionally* apply `-Zon-broken-pipe=kill` to tool builds and also not drop the
`-Zon-broken-pipe=kill` flag for rustc binary builds.
I could not figure out how to write a regression test for the `rustc --print=sysroot | false`
behavior on Unix, so this is a plain revert for now.
This revert will unfortunately reintroduce #130980 until we fix it again with the different approach.
See more details at <https://github.com/rust-lang/rust/issues/131059#issuecomment-2385822033> and in the timeline below.
### Timeline of kill-process-on-broken-pipe behavior changes
See [`unix_sigpipe` tracking issue #97889][#97889] for more context around unix sigpipe handling.
- From the very beginning since 2014, Rust binaries by default use `sig_ign`. This meant that if
output pipe is broken yet the program tries to use `println!` and such, there will be a broken
pipe panic from std. This lead to ICEs from e.g. `rustc --help | false` [#34376].
- [#49606] mitigated [#34376] by adding an explicit signal handler to `rustc_driver` register a
sigpipe handler with `SIG_DFL` which will cause the binary using `rustc_driver` to terminate if
`rustc_driver::set_sigpipe_handler()` is called. `rustc`'s main binary wrapper uses
`rustc_driver::set_sigpipe_handler()`, and so does `rustdoc`.
- A more universal way to set sigpipe behavior for Unix was introduced as part of [#97889], i.e. `#
[unix_sigpipe = "sig_dfl"]` attribute.
- [#102587] migrated `rustc` to use `#[unix_sigpipe = "sig_dfl"]` instead of
`rustc_driver::set_sigpipe_handler`.
- [#103495] migrated `rustdoc` to use `#[unix_sigpipe = "sig_dfl"]` instead of
`rustc_driver::set_sigpipe_handler`. `rustc_driver::set_sigpipe_handler` was removed.
- Following concerns about sigpipe setting UI in [#97889], the UI for specifying sigpipe behavior
was changed in [#124480] from `#[unix_sigpipe = "sig_dfl"]` attribute to the commmand line flag
`-Zon-broken-pipe=kill`.
- In the same PR, `#[unix_sigpipe = "sig_dfl"]` were removed from `rustc` and `rustdoc` main
binary crate entry points in favor of the command line flag. Kill-process-on-broken-pipe
behavior was preserved by adding `-Zon-broken-pipe=kill` for `rustdoc` tool build step and
`rustc` during compile steps.
- [#126934] added `-Zon-broken-pipe=kill` for tool builds *except* for cargo to help with some miri
tests because at the time the PR was written, this would lead to a couple of cargo test failures.
Conditionally setting `RUSTFLAGS` can lead to tool build invalidation, e.g. building `cargo`
without `-Zon-broken-pipe=kill` but `clippy` with the flag can lead to invalidation of the tool
build cache. This is not a problem at the time, because nothing (not even miri) tests built stage
1 cargo (all used initial cargo).
- In [#130634] we found out that `run-make` tests like `compiler-builtins` needed stage 1 cargo, not
just beta bootstrap cargo, because there can be changes that are present in stage 1 cargo but
absent in beta cargo, which was blocking a beta backport.
- [#130642] and later [#130739] now build stage 1 cargo. And as previously mentioned, since
`-Zon-broken-pipe=kill` was specifically *not* set for cargo, this caused tool build cache
invalidation meaning rebuilds of stage 1 even if nothing in source was changed due to differing
`RUSTFLAGS` since `run-make` also builds `rustdoc` and such [#130980].
[#34376]: https://github.com/rust-lang/rust/issues/34376
[#49606]: https://github.com/rust-lang/rust/pull/49606
[#97889]: https://github.com/rust-lang/rust/issues/97889
[#102587]: https://github.com/rust-lang/rust/pull/102587
[#103495]: https://github.com/rust-lang/rust/pull/103495
[#124480]: https://github.com/rust-lang/rust/pull/124480
[#130634]: https://github.com/rust-lang/rust/issues/130634
[#130642]: https://github.com/rust-lang/rust/pull/130642
[#130739]: https://github.com/rust-lang/rust/pull/130739
[#130980]: https://github.com/rust-lang/rust/issues/130980
[#131059]: https://github.com/rust-lang/rust/issues/131059
[^1]: https://github.com/rust-lang/rust/issues/131059#issuecomment-2385822033
r? ``@onur-ozkan`` (or bootstrap)
panic when an interpreter error gets unintentionally discarded
One important invariant of Miri is that when an interpreter error is raised (*in particular* a UB error), those must not be discarded: it's not okay to just check `foo().is_err()` and then continue executing.
This seems to catch new contributors by surprise fairly regularly, so this PR tries to make it so that *if* this ever happens, we get a panic rather than a silent missed UB bug. The interpreter error type now contains a "guard" that panics on drop, and that is explicitly passed to `mem::forget` when an error is deliberately discarded.
Fixes https://github.com/rust-lang/miri/issues/3855
Add `[Option<T>; N]::transpose`
This PR as a new unstable libs API, `[Option<T>; N]::transpose`, which permits going from `[Option<T>; N]` to `Option<[T; N]>`.
This new API doesn't have an ACP as it was directly asked by T-libs-api in https://github.com/rust-lang/rust/issues/97601#issuecomment-2372109119:
> [..] but it'd be trivial to provide a helper method `.transpose()` that turns array-of-Option into Option-of-array (**and we think that method should exist**; it already does for array-of-MaybeUninit).
r? libs
Update Unicode escapes in `/library/core/src/char/methods.rs`
`char::MAX` is inconsistent on how Unicode escapes should be formatted. This PR resolves that.
ptr::add/sub: do not claim equivalence with `offset(c as isize)`
In https://github.com/rust-lang/rust/pull/110837, the `offset` intrinsic got changed to also allow a `usize` offset parameter. The intention is that this will do an unsigned multiplication with the size, and we have UB if that overflows -- and we also have UB if the result is larger than `usize::MAX`, i.e., if a subsequent cast to `isize` would wrap. ~~The LLVM backend sets some attributes accordingly.~~
This updates the docs for `add`/`sub` to match that intent, in preparation for adjusting codegen to exploit this UB. We use this opportunity to clarify what the exact requirements are: we compute the offset using mathematical multiplication (so it's no problem to have an `isize * usize` multiplication, we just multiply integers), and the result must fit in an `isize`.
Cc `@rust-lang/opsem` `@nikic`
https://github.com/rust-lang/rust/pull/130239 updates Miri to detect this UB.
`sub` still has some cases of UB not reflected in the underlying intrinsic semantics (and Miri does not catch): when we subtract `usize::MAX`, then after casting to `isize` that's just `-1` so we end up adding one unit without noticing any UB, but actually the offset we gave does not fit in an `isize`. Miri will currently still not complain for such cases:
```rust
fn main() {
let x = &[0i32; 2];
let x = x.as_ptr();
// This should be UB, we are subtracting way too much.
unsafe { x.sub(usize::MAX).read() };
}
```
However, the LLVM IR we generate here also is UB-free. This is "just" library UB but not language UB.
Cc `@saethlin;` might be worth adding precondition checks against overflow on `offset`/`add`/`sub`?
Fixes https://github.com/rust-lang/rust/issues/130211
Rollup of 5 pull requests
Successful merges:
- #130630 (Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly)
- #131042 (Instantiate binders in `supertrait_vtable_slot`)
- #131079 (Update wasm-component-ld to 0.5.9)
- #131085 (make test_lots_of_insertions test take less long in Miri)
- #131088 (add fixme to remove LLVM_ENABLE_TERMINFO when minimal llvm version is 19)
r? `@ghost`
`@rustbot` modify labels: rollup
make test_lots_of_insertions test take less long in Miri
This is by far the slowest `std` test in Miri, taking >2min in https://github.com/rust-lang/miri-test-libstd CI. So let's make this `count` smaller. The runtime should be quadratic in `count` so reducing it to around 2/3 of it's previous value should cut the total time down to less than half -- making it still the slowest test, but by less of a margin. (And this way we still insert >64 elements into the HashMap, in case that power of 2 matters.)
Update wasm-component-ld to 0.5.9
This updates the `wasm-component-ld` linker binary for the `wasm32-wasip2` target to 0.5.9, pulling in a few bug fixes and recent updates.
Instantiate binders in `supertrait_vtable_slot`
`supertrait_vtable_slot` was previously using structural equality when probing for the vtable slot, which led to an ICE since we need a *subtype* match, not an exact match.
Fixes#131027
r? lcnr
Enable `f16` tests on non-GNU Windows
There is a MinGW ABI bug that prevents `f16` and `f128` from being usable on `windows-gnu` targets. This does not affect MSVC; however, we have `f16` and `f128` tests disabled on all Windows targets.
Update the gating to only affect `windows-gnu`, which means `f16` tests will be enabled. There is no effect for `f128` since the default fallback is `false`.
try-job: x86_64-msvc
try-job: i686-msvc
Stabilize expr_2021 fragment specifier in all editions
This is part of the `expr`/`expr_2021` fragment specifier for Edition 2024 (#123742). The RFC says we can support expr_2021 in as many editions as is practical, and there's nothing particularly hard about supporting it all the way back to 2015.
In editions 2021 and earlier, `expr` and `expr_2021` are synonyms. Their behavior diverges starting in Edition 2024. This is checked by the `expr_2021_inline_const.rs` test.
cc `@vincenzopalazzo` `@rust-lang/wg-macros` `@traviscross`
rustdoc: rewrite stability inheritance as a doc pass
Since doc inlining can almost arbitrarily change the module hierarchy, we can't just use the HIR ancestors of an item to compute its effective stability. This PR moves the stability inheritance that I implemented in https://github.com/rust-lang/rust/pull/130798 into a new doc pass `propagate-stability` that runs after doc inlining and uses the post-inlining ancestors of an item to correctly compute its effective stability.
fixes https://github.com/rust-lang/rust/issues/131020
r? `@notriddle`
There is a MinGW ABI bug that prevents `f16` and `f128` from being
usable on `windows-gnu` targets. This does not affect MSVC; however, we
have `f16` and `f128` tests disabled on all Windows targets.
Update the gating to only affect `windows-gnu`, which means `f16` tests
will be enabled. There is no effect for `f128` since the default
fallback is `false`.
Add `field@` and `variant@` doc-link disambiguators
I'm not sure if this is big enough to need an fcp or not, but this is something I found missing when trying to refer to a field in macro-generated docs, not knowing if a method might be defined as well. Obviously, there are definitely other uses.
In the case where it's not disambiguated, methods (and I suppose other associated items in the value namespace) still take priority, which `@jyn514` said was an oversight but I think is probably the desired behavior 99% of the time anyway - shadowing a field with an accessor method is a very common pattern. If fields and methods with the same name started conflicting, it would be a breaking change. Though, to quote them:
> jyn: maybe you can break this only if both [the method and the field] are public
> jyn: rustc has some future-incompat warning level
> jyn: that gets through -A warnings and --cap-lints from cargo
That'd be out of scope of this PR, though.
Fixes#80283
Rollup of 5 pull requests
Successful merges:
- #129638 (Hook up std::net to wasi-libc on wasm32-wasip2 target)
- #130877 (rustc_target: Add RISC-V atomic-related features)
- #130914 (Mark some more types as having insignificant dtor)
- #130961 (Enable `f16` tests on x86 Apple platforms)
- #130966 (make ptr metadata functions callable from stable const fn)
r? `@ghost`
`@rustbot` modify labels: rollup
make ptr metadata functions callable from stable const fn
So far this was done with a bunch of `rustc_allow_const_fn_unstable`. But those should be the exception, not the norm. If we are confident we can expose the ptr metadata APIs *indirectly* in stable const fn, we should just mark them as `rustc_const_stable`. And we better be confident we can do that since it's already been done a while ago. ;)
In particular this marks two intrinsics as const-stable: `aggregate_raw_ptr`, `ptr_metadata`. This should be uncontroversial, they are trivial to implement in the interpreter.
Cc `@rust-lang/wg-const-eval` `@rust-lang/lang`
Enable `f16` tests on x86 Apple platforms
These were disabled because Apple uses a special ABI for `f16`. `compiler-builtins` merged a fix for this in [1], which has since propagated to rust-lang/rust. Enable tests since there should be no remaining issues on these platforms.
[1]: https://github.com/rust-lang/compiler-builtins/pull/675
try-job: x86_64-apple-1
try-job: x86_64-apple-2
Mark some more types as having insignificant dtor
These were caught by https://github.com/rust-lang/rust/pull/129864#issuecomment-2376658407, which is implementing a lint for some changes in drop order for temporaries in tail expressions.
Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory.
See some discussion on #89144 for what makes a drop impl "significant"
Hook up std::net to wasi-libc on wasm32-wasip2 target
One of the improvements of the `wasm32-wasip2` target over `wasm32-wasip1` is better support for networking. Right now, p2 is just re-using the `std::net` implementation from p1. This PR adds a new net module for p2 that makes use of net from `sys_common` and calls wasi-libc functions directly.
There are currently a few limitations:
- Duplicating a socket is not supported by WASIp2 (directly returns an error)
- Peeking is not yet implemented in wasi-libc (we could let wasi-libc handle this, but I opted to directly return an error instead)
- Vectored reads/writes are not supported by WASIp2 (the necessary functions are available in wasi-libc, but they call WASIp1 functions which do not support sockets, so I opted to directly return an error instead)
- Getting/setting `TCP_NODELAY` is faked in wasi-libc (uses the fake implementation instead of returning an error)
- Getting/setting `SO_LINGER` is not supported by WASIp2 (directly returns an error)
- Setting `SO_REUSEADDR` is faked in wasi-libc (since this is done from `sys_common`, the fake implementation is used instead of returning an error)
- Getting/setting `IPV6_V6ONLY` is not supported by WASIp2 and will always be set for IPv6 sockets (since this is done from `sys_common`, wasi-libc will return an error)
- UDP broadcast/multicast is not supported by WASIp2 (since this is configured from `sys_common`, wasi-libc will return appropriate errors)
- The `MSG_NOSIGNAL` send flag is a no-op because there are no signals in WASIp2 (since explicitly setting this flag would require a change to `sys_common` and the result would be exactly the same, I opted to not set it)
Do those decisions make sense?
While working on this PR, I noticed that there is a `std::os::wasi::net::TcpListenerExt` trait that adds a `sock_accept()` method to `std::net::TcpListener`. Now that WASIp2 supports standard accept, would it make sense to remove this?
cc `@alexcrichton`
