Operations like is_aligned would return actively wrong results at compile-time,
i.e. calling it on the same pointer at compiletime and runtime could yield
different results. That's no good.
Instead of having hacks to make align_offset kind-of work in const-eval, just
use const_eval_select in the few places where it makes sense, which also ensures
those places are all aware they need to make sure the fallback behavior is
consistent.
get rid of a whole bunch of unnecessary rustc_const_unstable attributes
In general, when a `const fn` is still unstable, it doesn't need a `#[rustc_const_unstable]` attribute. The only exception is functions that internally use things that can't be used in stable const fn yet.
So this gets rid of a whole bunch of `#[rustc_const_unstable]` in libcore.
Remove unintended link
Since `#[link_section]` is enclosed in braces, it was being confused with a link during docs compilation.
This caused compilation to fail when running `x dist` since it emitted a warning regarding broken links.
Fix type reference in documents which was being confused with html tags.
Running `x dist` was failing due to it invoking commands with `-D warnings`, which emitted a warning about unclosed html tags.
library: fix some stability annotations
This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing https://github.com/rust-lang/rust/pull/132481.
### `core::char` / `std::char`
In https://github.com/rust-lang/rust/pull/26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0.
In https://github.com/rust-lang/rust/pull/49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0.
By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example.
### `{core,std}::array` and `{core,std}::array::TryFromSliceError`
In https://github.com/rust-lang/rust/pull/58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to https://github.com/rust-lang/rust/pull/95956 to existing yet.
Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in https://github.com/rust-lang/rust/pull/60657, but then getting backported for 1.35.0 in https://github.com/rust-lang/rust/pull/60838.
This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
feat(byte_sub_ptr): unstably add ptr::byte_sub_ptr
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr
both existing (they showed up at similar times so this union was never made). Adding these
is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (https://github.com/rust-lang/rust/issues/95892).
Original PR by ``@Gankra`` (https://github.com/rust-lang/rust/pull/121919), I am just reviving it. The 2nd commit (with a small docs tweak) is by me.
make const_alloc_layout feature gate only about functions that are already stable
The const_alloc_layout feature gate has two kinds of functions: those that are stable, but not yet const-stable, and those that are fully unstable.
I think we should split that up. So this PR makes const_alloc_layout just about functions that are already stable but waiting for const-stability; all the other functions now have their constness guarded by the gate that also guards their regular stability.
Cc https://github.com/rust-lang/rust/issues/67521
remove some unnecessary rustc_allow_const_fn_unstable
These are either unstable functions that don't need the attribute, or the attribute refers to a feature that is already stable.
Cleanup attributes around unchecked shifts and unchecked negation in const
The underlying intrinsic is marked as "safe to expose on stable", so we shouldn't need any `rustc_allow_const_fn_unstable(unchecked_shifts)` anywhere. However, bootstrap rustc doesn't yet have the new const stability checks, so these changes only apply under `cfg(not(bootstrap))`.
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr
both existing (they showed up at similar times so this union was never made). Adding these
is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (#95892).
Use Hacker's Delight impl in `i64::midpoint` instead of wide `i128` impl
This PR switches `i64::midpoint` and (`isize::midpoint` where `isize == i64`) to using our Hacker's Delight impl instead of wide `i128` implementation.
As LLVM seems to be outperformed by the complexity of signed 128-bits number compared to our Hacker's Delight implementation.[^1]
It doesn't seems like it's an improvement for the other sizes[^2], so we let them with the wide implementation.
[^1]: https://rust.godbolt.org/z/ravE75EYj
[^2]: https://rust.godbolt.org/z/fzr171zKh
r? libs
Rollup of 6 pull requests
Successful merges:
- #131984 (Stabilize if_let_rescope)
- #132151 (Ensure that resume arg outlives region bound for coroutines)
- #132157 (Remove detail from label/note that is already available in other note)
- #132274 (Cleanup op lookup in HIR typeck)
- #132319 (cg_llvm: Clean up FFI calls for setting module flags)
- #132321 (xous: sync: remove `rustc_const_stable` attribute on Condvar and Mutex new())
r? `@ghost`
`@rustbot` modify labels: rollup
xous: sync: remove `rustc_const_stable` attribute on Condvar and Mutex new()
These functions had `#[rustc_const_stable(feature = "const_locks", since = "1.63.0")]` on them because they were originally taken from `no_threads`. with d066dfd these no longer compile. Since other platforms do not have this attribute, remove it. This fixes the build for Xous.
Rc/Arc: don't leak the allocation if drop panics
Currently, when the last `Rc<T>` or `Arc<T>` is dropped and the destructor of `T` panics, the allocation will be leaked. This leak is unnecessary since the data cannot be (safely) accessed again and `Box` already deallocates in this case, so let's do the same for `Rc` and `Arc`, too.
These functions had `#[rustc_const_stable(feature = "const_locks", since
= "1.63.0")]` on them because they were originally taken from
`no_threads`. with d066dfd these no longer compile. Since other
platforms do not have this attribute, remove it. This fixes the build
for Xous.
Signed-off-by: Sean Cross <sean@xobs.io>
Split `boxed.rs` into a few modules
I wanted to add an impl for `Box<_>`, but was quickly discouraged by the 3K file. This splits off a couple bits, making it at least a bit more manageable.
r? ````@workingjubilee```` (I think you are not bothered by refactorings like this?)
Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.
Tracking issues: #131516, #131518
First commit implements `const_is_char_boundary`, second commit implements `const_str_split_at` (which depends on `const_is_char_boundary`)
~~I used `const_eval_select` for `is_char_boundary` since there is a comment about optimizations that would theoretically not happen with the simple `const`-compatible version (since `slice::get` is not `const`ifiable) cc #84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.~~
This changes `str::split_at_checked` to use a new private helper function `split_at_unchecked` (copied from `split_at_mut_unchecked`) that does pointer stuff instead of `get_unchecked`, since that is not currently `const`ifiable due to using the `SliceIndex` trait.
Lint against getting pointers from immediately dropped temporaries
Fixes#123613
## Changes:
1. New lint: `dangling_pointers_from_temporaries`. Is a generalization of `temporary_cstring_as_ptr` for more types and more ways to get a temporary.
2. `temporary_cstring_as_ptr` is removed and marked as renamed to `dangling_pointers_from_temporaries`.
3. `clippy::temporary_cstring_as_ptr` is marked as renamed to `dangling_pointers_from_temporaries`.
4. Fixed a false positive[^fp] for when the pointer is not actually dangling because of lifetime extension for function/method call arguments.
5. `core::cell::Cell` is now `rustc_diagnostic_item = "Cell"`
## Questions:
- [ ] Instead of manually checking for a list of known methods and diagnostic items, maybe add some sort of annotation to those methods in library and check for the presence of that annotation? https://github.com/rust-lang/rust/pull/128985#issuecomment-2318714312
## Known limitations:
### False negatives[^fn]:
See the comments in `compiler/rustc_lint/src/dangling.rs`
1. Method calls that are not checked for:
- `temporary_unsafe_cell.get()`
- `temporary_sync_unsafe_cell.get()`
2. Ways to get a temporary that are not recognized:
- `owning_temporary.field`
- `owning_temporary[index]`
3. No checks for ref-to-ptr conversions:
- `&raw [mut] temporary`
- `&temporary as *(const|mut) _`
- `ptr::from_ref(&temporary)` and friends
[^fn]: lint **should** be emitted, but **is not**
[^fp]: lint **should not** be emitted, but **is**
Add a new trait `proc_macro::ToTokens`
Tracking issue #130977
This PR adds a new trait `ToTokens`, implemented for types that can be interpolated inside a `quote!` invocation.
```rust
impl ToTokens for TokenTree
impl ToTokens for TokenStream
impl ToTokens for Literal
impl ToTokens for Ident
impl ToTokens for Punct
impl ToTokens for Group
impl<T: ToTokens + ?Sized> ToTokens for &T
impl<T: ToTokens + ?Sized> ToTokens for &mut T
impl<T: ToTokens + ?Sized> ToTokens for Box<T>
impl<T: ToTokens + ?Sized> ToTokens for Rc<T>
impl<T: ToTokens + ToOwned + ?Sized> ToTokens for Cow<'_, T>
impl<T: ToTokens> ToTokens for Option<T>
impl ToTokens for u{8,16,32,64,128}
impl ToTokens for i{8,16,32,64,128}
impl ToTokens for f{32,64}
impl ToTokens for {u,i}size
impl ToTokens for bool
impl ToTokens for char
impl ToTokens for str
impl ToTokens for String
impl ToTokens for CStr
impl ToTokens for CString
```
~This PR also implements the migration mentioned in the tracking issue, replacing `Extend<Token{Tree,Stream}>` with `Extend<T: ToTokens>`, and replacing `FromIterator<Token{Tree,Stream}>` with `FromIterator<T: ToTokens>`.~
**UPDATE**: Reverted.
```diff
-impl FromIterator<TokenTree> for TokenStream
-impl FromIterator<TokenStream> for TokenStream
+impl<T: ToTokens> FromIterator<T> for TokenStream
-impl Extend<TokenTree> for TokenStream
-impl Extend<TokenStream> for TokenStream
+impl<T: ToTokens> Extend<T> for TokenStream
```
I'm going to leave some comments in the review where I'm unsure and concerned.
r? ``@dtolnay``
CC ``@tgross35``
Make clearer that guarantees in ABI compatibility are for Rust only
cc https://github.com/rust-lang/rust/pull/132136#issuecomment-2439737631 -- it looks like we already had a note that I missed in my initial look here, but this goes further to emphasize the guarantees, including uplifting it to the top of the general documentation.
r? `@RalfJung`
As LLVM seems to be outperformed by the complexity of signed 128-bits
number compared to our Hacker's Delight implementation.[^1]
It doesn't seems like it's an improvement for the other sizes[^2], so we
let them with the wide implementation.
[^1]: https://rust.godbolt.org/z/ravE75EYj
[^2]: https://rust.godbolt.org/z/fzr171zKh
