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
Rename macro `SmartPointer` to `CoercePointee`
As per resolution #129104 we will rename the macro to better reflect the technical specification of the feature and clarify the communication.
- `SmartPointer` is renamed to `CoerceReferent`
- `#[pointee]` attribute is renamed to `#[referent]`
- `#![feature(derive_smart_pointer)]` gate is renamed to `#![feature(derive_coerce_referent)]`.
- Any mention of `SmartPointer` in the file names are renamed accordingly.
r? `@compiler-errors`
cc `@nikomatsakis` `@Darksonn`
Round negative signed integer towards zero in `iN::midpoint`
This PR changes the implementation of `iN::midpoint` (the signed variants) to round negative signed integers **towards zero** *instead* of negative infinity as is currently the case.
This is done so that the obvious expectations[^1] of `midpoint(a, b) == midpoint(b, a)` and `midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even more obvious implementation `(a + b) / 2` always true.
The unsigned variants `uN::midpoint` (which are being [FCP-ed](https://github.com/rust-lang/rust/pull/131784#issuecomment-2417188117)) already rounds towards zero, so there is no consistency issue.
cc `@scottmcm`
r? `@dtolnay`
[^1]: https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
Instead of towards negative infinity as is currently the case.
This done so that the obvious expectations of
`midpoint(a, b) == midpoint(b, a)` and
`midpoint(-a, -b) == -midpoint(a, b)` are true, which makes the even
more obvious implementation `(a + b) / 2` true.
https://github.com/rust-lang/rust/issues/110840#issuecomment-2336753931
