std::r#try! - avoid link to nightly docs
Use a relative link to the current version of rust-by-example rather than sending people to the nightly version.
Reflection TypeKind::FnPtr
This is for https://github.com/rust-lang/rust/issues/146922.
Const-eval currently lacks full support for function pointer (fn) types. We should implement handling of FnPtr TypeKind, covering safe and unsafe functions, Rust and custom ABIs, input and output types, higher-ranked lifetimes, and variadic functions.
- Implement handling of FnPtr TypeKind in const-eval, including:
- Unsafety flag (safe vs unsafe fn)
- ABI variants (Rust, Named(C), Named(custom))
- Input and output types
- Variadic function pointers
- Add const-eval tests covering:
- Basic Rust fn() pointers
- Unsafe fn() pointers
- Extern C and custom ABI pointers
- Functions with multiple inputs and output types
- Variadic functions
- Use const TypeId checks to verify correctness of inputs, outputs, and payloads
carryless_mul: mention the base
Arithmetic operations do not typically care about the base that is used to represent numbers, but this one does. Mentioning that makes it easier to understand the operation, I think.
Cc @folkertdev
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute
It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.
Most of the diff is just the line number changes in `malformed-attrs.stderr`.
Add documentation note about signed overflow direction
In https://github.com/rust-lang/rust/issues/151989#issuecomment-3845282666 I noticed that signed overflow direction can be determined by returned wrapped value. It is not very obvious (especially, assuming additional `carry: bool` summand), but it is important if we want to add new leading (signed) limb to big integer in this case.
Examples for small summands `x, y: i8` with result extension:
| x | y | overflow | result as (u8, i8) |
| ---- | ---- | -------- | ------------------ |
| -1 | -128 | true | (127, -1) |
| 0 | -1 | false | (255, -1) |
| 2 | 2 | false | (4, 0) |
| 127 | 1 | true | (128, 0) |
Here is general proof.
1. Set $s=2^{N-1}$ and let's say `iN::carrying_add(x, y, c)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x + y + c + 2s,& x + y + c \le -s-1,\\
x+y+c-2s,& x+y+c\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-s+0+2s =0;\qquad
\mathrm{result}=x + y + c + 2s\le -s-1+2s = s - 1,
$$
so we obtain $[0; s-1]$ which is exactly range of non-negative `iN`.
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x+y+c-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 + s-1+1-2s = -1,
$$
that is, $[-s,-1]$ which is exactly range of negative `iN`.
2. Now suppose that `iN::borrowing_sub(x,y,b)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x - y - b + 2s,& x - y - b \le -s-1,\\
x - y - b - 2s,& x - y - b\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-(s-1)-1+2s =0;\qquad
\mathrm{result}=x - y - b + 2s\le -s-1+2s = s - 1.
$$
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x-y-b-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 - (-s) - 0 - 2s = -1.
$$
Improve `VaList` stdlib docs
tracking issue: https://github.com/rust-lang/rust/issues/44930
Some improvements to the `VaList` documentation, at least adding an example. We should link to the reference for c-variadic functions once stable. I've tried to call out explicitly that the type is meant for sending over the FFI boundary.
r? workingjubilee
cc @tgross35
Implement accepted ACP for `MAX_EXACT_INTEGER` and `MIN_EXACT_INTEGER`
on `f16`, `f32`, `f64`, and `f128`
Add tests to `coretests/tests/floats/mod.rs`
Disable doc tests for i586 since float<->int casts return incorrect
results
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.
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
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
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.
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)]`
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.
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.
Do not require `'static` for obtaining reflection information.
tracking issue rust-lang/rust#142577
This does not affect the stable `TypeId::of`, as that has its own `'static` bound.
But it will allow obtaining `TypeId`s for non-static types via the reflection API. To obtain such a `TypeId` for any type, just use `Type::of::<(T,)>().kind` to extract the first field of a tuple.
This effectively reintroduces rust-lang/rust#41875, which @rust-lang/lang decided against allowing back in 2018 due to lack of sound use cases. We will thus need to have a T-lang meeting specifically about `TypeId` for non-static types before *stabilizing* any part of reflection (in addition to T-lang meetings about reflection in general). I'm adding an explicit point about this to the tracking issue.
cc @scottmcm @joshtriplett @9SonSteroids @SpriteOvO @izagawd @BD103
UnsafePinned: implement opsem effects of UnsafeUnpin
This implements the next step for https://github.com/rust-lang/rust/issues/125735: actually making `UnsafePinned` have special opsem effects by suppressing the `noalias` *even if* the type is wrapped in an `Unpin` wrapper.
For backwards compatibility we also still keep the `Unpin` hack, i.e. a type must be both `Unpin` and `UnsafeUnpin` to get `noalias`.
Optimize indexing slices and strs with inclusive ranges
Instead of separately checking for `end == usize::MAX` and `end + 1 > slice.len()`, we can check for `end >= slice.len()`. Also consolidate all the str indexing related panic functions into a single function which reports the correct error depending on the arguments, as the slice indexing code already does.
The downside of all this is that the panic message is slightly less specific when trying to index with `[..=usize::MAX]`: instead of saying "attempted to index str up to maximum usize" it just says "end byte index {end} out of bounds". But this is a rare enough case that I think it is acceptable
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.
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.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
