simd_shuffle: require index argument to be a vector
Remove some codegen hacks by forcing the SIMD shuffle `index` argument to be a vector, which means (thanks to https://github.com/rust-lang/rust/pull/128537) that it will automatically be passed as an immediate in LLVM. The only special-casing we still have is for the extra sanity-checks we add that ensure that the indices are all in-bounds. (And the GCC backend needs to do a bunch of work since the Rust intrinsic is modeled after what LLVM expects, which seems to be quite different from what GCC expects.)
Fixes https://github.com/rust-lang/rust/issues/128738, see that issue for more context.
fix doc comments for Peekable::next_if(_eq)
Fix references to a nonexistent `consume` function in the doc comments for `Peekable::next_if` and `Peekable::next_if_eq`.
some const cleanup: remove unnecessary attributes, add const-hack indications
I learned that we use `FIXME(const-hack)` on top of the "const-hack" label. That seems much better since it marks the right place in the code and moves around with the code. So I went through the PRs with that label and added appropriate FIXMEs in the code. IMO this means we can then remove the label -- Cc ``@rust-lang/wg-const-eval.``
I also noticed some const stability attributes that don't do anything useful, and removed them.
r? ``@fee1-dead``
move some const fn out of the const_ptr_as_ref feature
When a `const fn` is still `#[unstable]`, it should generally use the same feature to track its regular stability and const-stability. Then when that feature moves towards stabilization we can decide whether the const-ness can be stabilized as well, or whether it should be moved into a new feature.
Also, functions like `ptr::as_ref` (which returns an `Option<&mut T>`) require `is_null`, which is tricky and blocked on some design concerns (see #74939). So move those to the is_null feature gate, as they should be stabilized together with `ptr.is_null()`.
Affects #91822, #122034, #75402, https://github.com/rust-lang/rust/issues/74939
bootstrap `naked_asm!` for `compiler-builtins`
tracking issue: https://github.com/rust-lang/rust/issues/90957
parent PR: https://github.com/rust-lang/rust/pull/128651
in this PR, `naked_asm!` is added as an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later.
The `naked_asm!` macro must be introduced first so that we can upgrade `compiler-builtins` to use it, and can then change the implementation of `naked_asm!` in https://github.com/rust-lang/rust/pull/128651
I've added some usages for `naked_asm!` in the tests, so we can be confident that it works, but I've left upgrading the whole test suite to the parent PR.
r? ``@Amanieu``
in this commit, `naked_asm!` is an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later.
const: make ptr.is_null() stop execution on ambiguity
This seems better than saying `false` -- saying `false` is in fact actively unsound if `NonNull` then uses this to permit putting this pointer inside of it, but at runtime it turns out to be null.
Part of https://github.com/rust-lang/rust/issues/74939
Cc ```@rust-lang/wg-const-eval```
remove 'const' from 'Option::iter'
This is kind of pointless to be a `const fn` since you can't do anything with the iterator. It is also the only `const fn iter*` in the entire standard library. It probably got constified when `~const` traits got added everywhere, and then was forgotten to be de-constified when that was undone.
The rest of the const_option feature seems like it can reasonably be stabilized, but this one IMO should not be stabilized, and it's not worth creating a new tracking issue.
Cc https://github.com/rust-lang/rust/issues/67441
Rollup of 10 pull requests
Successful merges:
- #126452 (Implement raw lifetimes and labels (`'r#ident`))
- #129555 (stabilize const_float_bits_conv)
- #129594 (explain the options bootstrap passes to curl)
- #129677 (Don't build by-move body when async closure is tainted)
- #129847 (Do not call query to compute coroutine layout for synthetic body of async closure)
- #129869 (add a few more crashtests)
- #130009 (rustdoc-search: allow trailing `Foo ->` arg search)
- #130046 (str: make as_mut_ptr and as_bytes_mut unstably const)
- #130047 (Win: Add dbghelp to the list of import libraries)
- #130059 (Remove the unused `llvm-skip-rebuild` option from x.py)
r? `@ghost`
`@rustbot` modify labels: rollup
str: make as_mut_ptr and as_bytes_mut unstably const
`@rust-lang/libs-api` the corresponding non-mutable methods are already const fn, so this seems pretty trivial. I hope this is small enough that it does not need an ACP? :)
I would like to get these stabilized ASAP because I want to avoid people doing `s.as_ptr().cast_mut()`, which is UB if they ever write to it, but is already const-stable.
TODO: create a tracking issue.
