replace box_new with lower-level intrinsics
The `box_new` intrinsic is super special: during THIR construction it turns into an `ExprKind::Box` (formerly known as the `box` keyword), which then during MIR building turns into a special instruction sequence that invokes the exchange_malloc lang item (which has a name from a different time) and a special MIR statement to represent a shallowly-initialized `Box` (which raises [interesting opsem questions](https://github.com/rust-lang/rust/issues/97270)).
This PR is the n-th attempt to get rid of `box_new`. That's non-trivial because it usually causes a perf regression: replacing `box_new` by naive unsafe code will incur extra copies in debug builds, making the resulting binaries a lot slower, and will generate a lot more MIR, making compilation measurably slower. Furthermore, `vec!` is a macro, so the exact code it expands to is highly relevant for borrow checking, type inference, and temporary scopes.
To avoid those problems, this PR does its best to make the MIR almost exactly the same as what it was before. `box_new` is used in two places, `Box::new` and `vec!`:
- For `Box::new` that is fairly easy: the `move_by_value` intrinsic is basically all we need. However, to avoid the extra copy that would usually be generated for the argument of a function call, we need to special-case this intrinsic during MIR building. That's what the first commit does.
- `vec!` is a lot more tricky. As a macro, its details leak to stable code, so almost every variant I tried broke either type inference or the lifetimes of temporaries in some ui test or ended up accepting unsound code due to the borrow checker not enforcing all the constraints I hoped it would enforce. I ended up with a variant that involves a new intrinsic, `fn write_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<MaybeUninit<T>>`, that writes a value into a `Box<MaybeUninit<T>>` and returns that box again. In exchange we can get rid of somewhat similar code in the lowering for `ExprKind::Box`, and the `exchange_malloc` lang item. (We can also get rid of `Rvalue::ShallowInitBox`; I didn't include that in this PR -- I think @cjgillot has a commit for this somewhere [around here](https://github.com/rust-lang/rust/pull/147862/commits).)
See [here](https://github.com/rust-lang/rust/pull/148190#issuecomment-3457454814) for the latest perf numbers. Most of the regressions are in deep-vector which consists entirely of an invocation of `vec!`, so any change to that macro affects this benchmark disproportionally.
This is my first time even looking at MIR building code, so I am very low confidence in that part of the patch, in particular when it comes to scopes and drops and things like that.
I also had do nerf some clippy tests because clippy gets confused by the new expansion of `vec!` so it makes fewer suggestions when `vec!` is involved.
### `vec!` FAQ
- Why does `write_box_via_move` return the `Box` again? Because we need to expand `vec!` to a bunch of method invocations without any blocks or let-statements, or else the temporary scopes (and type inference) don't work out.
- Why is `box_assume_init_into_vec_unsafe` (unsoundly!) a safe function? Because we can't use an unsafe block in `vec!` as that would necessarily also include the `$x` (due to it all being one big method invocation) and therefore interpret the user's code as being inside `unsafe`, which would be bad (and 10 years later, we still don't have safe blocks for macros like this).
- Why does `write_box_via_move` use `Box` as input/output type, and not, say, raw pointers? Because that is the only way to get the correct behavior when `$x` panics or has control effects: we need the `Box` to be dropped in that case. (As a nice side-effect this also makes the intrinsic safe, which is imported as explained in the previous bullet.)
- Can't we make it safe by having `write_box_via_move` return `Box<T>`? Yes we could, but there's no easy way for the intrinsic to convert its `Box<MaybeUninit<T>>` to a `Box<T>`. Transmuting would be unsound as the borrow checker would no longer properly enforce that lifetimes involved in a `vec!` invocation behave correctly.
- Is this macro truly cursed? Yes, yes it is.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#148206 (Deduplicated float tests and unified in floats/mod.rs)
- rust-lang/rust#150601 (support c-variadic functions in `rustc_const_eval`)
- rust-lang/rust#152103 (Consider captures to be used by closures that unwind)
- rust-lang/rust#152296 (Port `rust_nonnull_optimization_guaranteed` and `rustc_do_not_const_check` to the new attribute parser)
- rust-lang/rust#152648 (Remove timing assertion from `oneshot::send_before_recv_timeout`)
- rust-lang/rust#152686 (bootstrap: Inline the `is_tool` check for setting `-Zforce-unstable-if-unmarked`)
Failed merges:
- rust-lang/rust#152512 (core: Implement feature `float_exact_integer_constants`)
bootstrap: Inline the `is_tool` check for setting `-Zforce-unstable-if-unmarked`
`Mode::is_tool` is the sort of method that looks general-purpose, but is only actually used for a very specific purpose, to control the setting of `-Zforce-unstable-if-unmarked`.
It is therefore clearer to inline the mode check, which makes it easier to see how the condition affects the result.
I have tried to add some comments explaining why we set that flag, but they are based on my own recent investigations, so I'm not 100% confident that they're accurate.
Remove timing assertion from `oneshot::send_before_recv_timeout`
This test regularly spuriously fails in CI, such as https://github.com/rust-lang/rust/pull/152632#issuecomment-3902778366
We can just remove the assertion but I'd like to understand why, so I'm adding more information to the assert
Consider captures to be used by closures that unwind
Assignments to a captured variable within a diverging closure should not be considered unused if the divergence is caught.
This patch considers such assignments/captures to be used by diverging closures irrespective of whether the divergence is caught, but better a false negative unused lint than a false positive one (the latter having caused a stable-to-stable regression).
Fixesrust-lang/rust#152079
r? compiler
support c-variadic functions in `rustc_const_eval`
tracking issue: https://github.com/rust-lang/rust/issues/44930
The new `GlobalAlloc::VaList` is used to create an `AllocId` that represents the variable argument list of a frame. The allocation itself does not store any data, all we need is the unique identifier.
The actual variable argument list is stored in `Memory`, and keyed by the `AllocId`. The `Frame` also stores this `AllocId`, so that when a frame is popped, it can deallocate the variable arguments.
At "runtime" a `VaList` value stores a pointer to the global allocation in its first bytes. The provenance on this pointer can be used to retrieve its `AllocId`, and the offset of the pointer is used to store the index of the next argument to read from the variable argument list.
Miri does not yet support `va_arg`, but I think that can be done separetely?
r? @RalfJung
cc @workingjubilee
Deduplicated float tests and unified in floats/mod.rs
In this PR Float tests are deduplicated and are unified in floats/mod.rs, as discussed in https://github.com/rust-lang/rust/issues/141726.
The moved float tests are:
-> test_powf
-> test_exp
-> test_exp2
-> test_ln
-> test_log_generic
-> test_log2
-> test_log10
-> test_asinh
-> test_acosh
-> test_atanh
-> test_gamma
-> test_ln_gamma
Closes: https://github.com/rust-lang/rust/issues/141726
Big query system cleanups
Recent PRs have moved a lot of code from `rustc_query_system` to `rustc_middle` and `rustc_query_impl`, where this code now has access to `TyCtxt`, e.g. rust-lang/rust#152419, rust-lang/rust#152516. As a result, a lot of abstraction and indirection that existed to work around this limitation is no longer necessary. This PR removes a lot of it.
r? @Zalathar
feat: show what lint was overruled
We can't `#[allow]` a whole lint group if any of its members is forbidden, but the offending member is not currently shown if it was forbidden from the command line.
Before/after:
```diff
$ rustc -F dead_code - <<< '#![allow(unused)]'
error[E0453]: allow(unused) incompatible with previous forbid
--> <anon>:1:10
|
1 | #![allow(unused)]
| ^^^^^^ overruled by previous forbid
|
- = note: `forbid` lint level was set on command line
+ = note: `forbid` lint level was set on command line (`-F dead_code`)
error: aborting due to 1 previous error
```
@rustbot label +A-diagnostics +A-lints +D-terse
New float tests in core are failing on clif with issues like the
following:
Undefined symbols for architecture arm64:
"_coshf128", referenced from:
__RNvMNtCshY0fR2o0hOA_3std4f128C4f1284coshCs5TKtJxXQNGL_9coretests in coretests-e38519c0cc90db54.coretests.44b6247a565e10d1-cgu.10.rcgu.o
"_exp2f128", referenced from:
__RNvMNtCshY0fR2o0hOA_3std4f128C4f1284exp2Cs5TKtJxXQNGL_9coretests in coretests-e38519c0cc90db54.coretests.44b6247a565e10d1-cgu.10.rcgu.o
...
Disable f128 math unless the symbols are known to be available, which
for now is only glibc targets. This matches the LLVM backend.
Fix const normalization for generic const items with trait assoc consts
In `try_fold_free_or_assoc`, the check for whether the normalization result needs further normalization only considered types, not constants. This caused generic const items marked with `#[type_const]` that reference trait associated consts to only partially normalize—the outer const would be expanded, but the inner associated const would remain unevaluated, resulting in an ICE in borrowck.
closerust-lang/rust#151647
r? BoxyUwU
(Based on git blame)
Pass alignments through the shim as `Alignment` (not `usize`)
We're using `Layout` on both sides, so might as well skip the transmutes back and forth to `usize`.
The mir-opt test shows that doing so allows simplifying the boxed-slice drop slightly, for example.
It was just a dummy implementation to workarround the fact that thin
local lto is the default in rustc. By adding a thin_lto_supported thin
local lto can be automatically disabled for cg_gcc, removing the need
for this dummy implementation. This makes improvements to the LTO
handling on the cg_ssa side a lot easier.
Use `scope` for `par_slice` instead of `join`
This uses `scope` instead of nested `join`s in `par_slice` so that each group of items are independent and do not end up blocking on another.
unwind/wasm: fix compile error by wrapping wasm_throw in unsafe block
This fix rust-std compile error on wasm32-unknown-unknown with panic=unwind because of `#![deny(unsafe_op_in_unsafe_fn)]`
Add regression test for #141738Closesrust-lang/rust#141738
- Add a regression test for rust-lang/rust#141738
- Using a struct constructor (`DefKind::Ctor(Struct, Const)`) as an array repeat count with `#![feature(min_generic_const_args)]` used to ICE in const alias normalization
- Fixed by rust-lang/rust#150704, which added const constructor support for mGCA. This test covers the **error path** (struct ctor where `usize` is expected), which was not covered by the tests in rust-lang/rust#150704
Include `library/stdarch` for `CURRENT_RUSTC_VERSION` updates
Our tool `replace-version-placeholder` uses the `tidy` file walker and its
directory filter, but that skips `library/stdarch` which we do need for public
stability markers. This PR adds a local filter function that explicitly allows
that path.
The commit for 1.94 `stdarch` updates is coming from beta rust-lang/rust#152187.
ci: Lock cross toolchain version and update docs
This PR locks the cross-toolchain component version to avoid unexpected changes when bumping crosstool-ng, and updates the toolchain configuration in the docs to match the actual setup.
try-job: dist-arm-linux-musl
try-job: dist-loongarch64-linux
try-job: dist-loongarch64-musl
try-job: dist-powerpc64-linux-musl
try-job: dist-powerpc64le-linux-gnu
try-job: dist-powerpc64le-linux-musl
Test(lib/win/net): Skip UDS tests when under Win7
Unix Domain Socket support has only been added to Windows since Windows 10 Insider Preview Build 17063. Thus, it has no chance of ever being supported under Windows 7, making current tests fail. This therefore adds the necessary in order to make the tests dynamically skip when run under Windows 7, 8, and early 10, as it does not trigger linker errors.
cc rust-lang/rust#150487 @roblabla
@rustbot label T-libs A-io O-windows-7
Improve write! and writeln! error when called without destination
Fixesrust-lang/rust#152493
Adds catch-all arms to `write!` and `writeln!` macros so that calling them without a destination (e.g., `write!("S")` instead of `write!(f, "S")`) gives a clear error instead of the cryptic "unexpected end of macro invocation" pointing at macro internals.
r? @estebank
implement `carryless_mul`
tracking issue: https://github.com/rust-lang/rust/issues/152080
ACP: https://github.com/rust-lang/libs-team/issues/738
This defers to LLVM's `llvm.clmul` when available, and otherwise falls back to a method from the `polyval` crate ([link](https://github.com/RustCrypto/universal-hashes/blob/master/polyval/src/field_element/soft/soft64.rs)).
Some things are missing, which I think we can defer:
- the ACP has some discussion about additional methods, but I'm not sure exactly what is wanted or how to implement it efficiently
- the SIMD intrinsic is not yet `const` (I think I ran into a bootstrapping issue). That is fine for now, I think in `stdarch` we can't really use this intrinsic at the moment, we'd only want the scalar version to replace some riscv intrinsics.
- the SIMD intrinsic is not implemented for the gcc and cranelift backends. That should be reasonably straightforward once we have a const eval implementation though.
diagnostics: add note when param-env shadows global impl
This PR adds a diagnostics note when param-env shadows global impl as discussed in https://github.com/rust-lang/rust/issues/149910
It adds a note explaining that the definition is hidden by the generic bound.
r?lcnr
