| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Ensure consistent drop for panicking drop in hint::select_unpredictable
There are a few alternatives to the implementation. The principal problem is that the selected value must be owned (in the sense of having a drop flag of sorts) when the unselected value is dropped, such that panic unwind goes through the drop of both. This ownership must then be passed on in return when the drop went smoothly.
The basic way of achieving this is by extracting the selected value first, at the cost of relying on the optimizer a little more for detecting the copy as constructing the return value despite having a place in the body. Unfortunately, that causes LLVM to discard the !unpredictable annotation (for some reason that is beyond my comprehension of LLVM).
<details>
<summary>Extract from the build log showing an unannotated select being used</summary>
```
2025-08-09T16:51:06.8790764Z 39: define noundef i64 `@test_int2(i1` noundef zeroext %p, i64 noundef %a, i64 noundef %b) unnamed_addr #0 personality ptr `@rust_eh_personality` {
2025-08-09T16:51:06.8791368Z check:47'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
2025-08-09T16:51:06.8791700Z 40: start:
2025-08-09T16:51:06.8791858Z check:47'0 ~~~~~~~
2025-08-09T16:51:06.8792043Z 41: %ret.i = select i1 %p, i64 %a, i64 %b
2025-08-09T16:51:06.8792293Z check:47'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-08-09T16:51:06.8792686Z check:47'1 ? possible intended match
2025-08-09T16:51:06.8792946Z 42: ret i64 %ret.i
2025-08-09T16:51:06.8793127Z check:47'0 ~~~~~~~~~~~~~~~~
```
</details>
So instead, this PR includes a guard to drop the selected `MaybeUnit<T>` which is active only for the section where the unselected value is dropped. That leaves the code for selecting the result intact leading to the expected ir. That complicates the 'unselection' process a little bit since we require _both_ values as a result of that intrinsic call. Since the arguments alias, this portion as well as the drop guard uses raw pointers.
Closes: rust-lang/rust#145148
Prior: rust-lang/rust#139977
|
|
|
|
Instead of a tuple, select the dropped value and its guard with two
separate calls to the intrinsic which makes both calls have a
pointer-valued argument that should be simpler in codegen. Use the same
condition on all (not an inverted condition) to clarify the intent of
parallel selection. This should also be a simpler value-dependency chain
if the guard is deduced unused (i.e. drop_in_place a noop for the type).
|
|
|
|
It seems important for LLVM that we select on the values by-value
instead of reading and have no intermediate store. So make sure the
guards selects both potential drops but defers the return value to the
second selection. Since the two options alias we use raw mutable
pointers instead of mutable references as before.
|
|
There are a few alternatives to the implementation. The principal
problem is that the selected value must be owned (in the sense of having
any drop flag of sorts) when the unselected value is dropped, such that
panic unwind goes through the drop of both. This ownership must then be
passed on in return when the drop went smoothly. The basic way of
achieving this is by extracting the selected value first, at the cost of
relying on the optimizer a little more for detecting the copy as
constructing the return value despite having a place in the body.
|
|
Because doc code does not get automatically formatted, some doc code has
creative placements of comments that automatic formatting can't handle.
Reformat those comments to make the resulting code support standard Rust
formatting without breaking; this is generally an improvement to
readability as well.
Some comments are not indented to the prevailing indent, and are instead
aligned under some bit of code. Indent them to the prevailing indent,
and put spaces *inside* the comments to align them with code.
Some comments span several lines of code (which aren't the line the
comment is about) and expect alignment. Reformat them into one comment
not broken up by unrelated intervening code.
Some comments are placed on the same line as an opening brace, placing
them effectively inside the subsequent block, such that formatting would
typically format them like a line of that block. Move those comments to
attach them to what they apply to.
Some comments are placed on the same line as a one-line braced block,
effectively attaching them to the closing brace, even though they're
about the code inside the block. Reformat to make sure the comment will
stay on the same line as the code it's commenting.
|
|
Add some track_caller info to precondition panics
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.
The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.
The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
|
|
|
|
This updates some doctests that fail to run on wasm. We will soon be
supporting cross-compiled doctests, and the test-various job fails to
run these tests. These tests fail because wasm32-wasip1 does not support
threads.
|
|
|
|
Clarify black_box warning a bit
Trying to bring the docs on black_box more in line with the advice that we have discussed in Zulip.
https://github.com/rust-lang/rust/pull/140341#issuecomment-2832592382
|
|
And note that the same limitation applies to all LLVM-based compilers
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
FCP completed in tracking issue #133962.
|
|
This intrinsic doesn't drop the value that is not selected so this is
manually done in the public function that wraps the intrinsic.
|
|
|
|
(cherry picked from commit e4840ce59bdddb19394df008c5c26d9c493725f8)
|
|
|
|
These currently point to rust-lang/rust#26179, which is nearly a decade
old and has a lot of outdated discussion. Move these features to a new
tracking issue specifically for the recently added API.
New tracking issue: https://github.com/rust-lang/rust/issues/136873
|
|
This has been unstably const since [1], but a tracking issue was never
created. Per discussion on Zulip [2], there should not be any blockers
to making this const-stable. The function does not provide any
functionality at compile time but does allow code reuse between const-
and non-const functions, so stabilize it here.
[1]: https://github.com/rust-lang/rust/pull/92226
[2]: https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const_black_box
|
|
Reexport likely/unlikely in std::hint
Since `likely`/`unlikely` should be working now, we could reexport them in `std::hint`. I'm not sure if this is already approved or if it requires approval
Tracking issue: #26179
|
|
|
|
|
|
Co-authored-by: Ben Kimock <kimockb@gmail.com>
|
|
|
|
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
|
|
there should probably be a lint against this in rustdoc, it causes
too many lines to be shown in the short documentation overviews
expecially noticable for the slice primative type:
https://doc.rust-lang.org/std/index.html
|
|
Bump bootstrap compiler to new beta
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
Signed-off-by: cuishuang <imcusg@gmail.com>
|
|
Stabilize `hint::assert_unchecked`
Make the following API stable, including const:
```rust
// core::hint, std::hint
pub const unsafe fn assert_unchecked(p: bool);
```
This PR also reworks some of the documentation and adds an example.
Tracking issue: https://github.com/rust-lang/rust/issues/119131
FCP: https://github.com/rust-lang/rust/issues/119131#issuecomment-1906394087. The docs update should resolve the remaining concern.
|
|
Make both `hint_assert_unchecked` and `const_hint_assert_unchecked`
stable as `hint_assert_unchecked`.
|
|
Rearrange the sections and add an example to
`core::hint::assert_unchecked`.
|
|
People were tripped up by the "precludes", interpreting it that this function
must not ever be used in cryptographic contexts rather than the std lib merely
making zero promises about it being fit-for-purpose.
What remains unchanged is that if someone does try to use it *despite the warnings*
then it is on them to pin their compiler versions and verify the assembly of every
single binary build they do.
|
|
|
|
These macros and functions are not intrinsics, after all.
|
|
|
|
|
|
Needle and haystack are actually not the same, they remain constant.
|
|
|
|
Improve wording of `hint::black_box` docs
The wording is a bit confusing.
squash of #109634
|
|
The wording is a bit confusing.
Co-authored-by: Chris Denton <christophersdenton@gmail.com>
|
|
|
|
black_box doc corrections for clarification - Issue #107957
Made a complete pass through the docs to help resolve https://github.com/rust-lang/rust/issues/107957
No code changes, just documentation
`@rustbot` label +T-libs-api -T-libs
|
|
|
|
|
|
|
|
|
|
|
