Implement a lint for implicit autoref of raw pointer dereference - take 2
*[t-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097)*
This PR aims at implementing a lint for implicit autoref of raw pointer dereference, it is based on #103735 with suggestion and improvements from https://github.com/rust-lang/rust/pull/103735#issuecomment-1370420305.
The goal is to catch cases like this, where the user probably doesn't realise it just created a reference.
```rust
pub struct Test {
data: [u8],
}
pub fn test_len(t: *const Test) -> usize {
unsafe { (*t).data.len() } // this calls <[T]>::len(&self)
}
```
Since #103735 already went 2 times through T-lang, where they T-lang ended-up asking for a more restricted version (which is what this PR does), I would prefer this PR to be reviewed first before re-nominating it for T-lang.
----
Compared to the PR it is as based on, this PR adds 3 restrictions on the outer most expression, which must either be:
1. A deref followed by any non-deref place projection (that intermediate deref will typically be auto-inserted)
2. A method call annotated with `#[rustc_no_implicit_refs]`.
3. A deref followed by a `addr_of!` or `addr_of_mut!`. See bottom of post for details.
There are several points that are not 100% clear to me when implementing the modifications:
- ~~"4. Any number of automatically inserted deref/derefmut calls." I as never able to trigger this. Am I missing something?~~ Fixed
- Are "index" and "field" enough?
----
cc `@JakobDegen` `@WaffleLapkin`
r? `@RalfJung`
try-job: dist-various-1
try-job: dist-various-2
Create `Atomic<T>` type alias (rebase)
Rebase of #130543.
Additional changes:
- Switch from `allow` to `expect` for `private_bounds` on `AtomicPrimitive`
- Unhide `AtomicPrimitive::AtomicInner` from docs, because rustdoc shows the definition `pub type Atomic<T> = <T as AtomicPrimitive>::AtomicInner;` and generated links for it.
- `NonZero` did not have this issue, because they kept the new alias private before the direction was changed.
- Use `Atomic<_>` in more places, including inside `Once`'s `Futex`. This is possible thanks to https://github.com/rust-lang/rust-clippy/pull/14125
The rest will either get moved back to #130543 or #130543 will be closed in favor of this instead.
---
* ACP: https://github.com/rust-lang/libs-team/issues/443#event-14293381061
* Tracking issue: #130539
Update safety documentation for `CString::from_ptr` and `str::from_boxed_utf8_unchecked`
## PR Description
This PR addresses missing safety documentation for two APIs:
**1. alloc::ffi::CStr::from_raw**
- `Alias`: The pointer must not be aliased (accessed via other pointers) during the reconstructed CString's lifetime.
- `Owning`: Calling this function twice on the same pointer and creating two objects with overlapping lifetimes, introduces two alive owners of the same memory. This may result in a double-free.
- `Dangling`: The prior documentation required the pointer to originate from CString::into_raw, but this constraint is incomplete. A validly sourced pointer can also cause undefined behavior (UB) if it becomes dangling. A simple Poc for this situation:
```
use std::ffi::CString;
use std::os::raw::c_char;
fn create_dangling() -> *mut c_char {
let local_ptr: *mut c_char = {
let valid_data = CString::new("valid").unwrap();
valid_data.into_raw()
};
unsafe {
let _x = CString::from_raw(local_ptr);
}
local_ptr
}
fn main() {
let dangling = create_dangling();
unsafe {let _y = CString::from_raw(dangling);} // Cause UB!
}
```
**2. alloc::str::from_boxed_utf8_unchecked**
- `ValidStr`: Bytes must contain a valid UTF-8 sequence.
Stabilise `std::ffi::c_str`
This finished FCP in #112134 but never actually got a stabilisation PR. Since the FCP in #120048 recently passed to add the `os_str` module, it would be nice to also merge this too, to ensure that both get added in the next version.
Note: The added stability attributes which *somehow* were able to be omitted before (rustc bug?) were added based on the fact that they were added in 302551388b1942bb4216bb5a15d9d55cee3643a8, which ended up in 1.85.0.
Closes: https://github.com/rust-lang/rust/issues/112134
r? libs-api
I found these by grepping for `&[a-z_\.]*\.clone()`, i.e. expressions
like `&a.b.clone()`, which are sometimes unnecessary clones, and also
looking at clones nearby to cases like that.
fix incorrect type in cstr `to_string_lossy()` docs
Restoring what it said prior to commit 67065fe in which it was changed incorrectly with no supporting explanation.
Closes#139835.
Replace last `usize` -> `ptr` transmute in `alloc` with strict provenance API
This replaces the `usize -> ptr` transmute in `RawVecInner::new_in` with a strict provenance API (`NonNull::without_provenance`).
The API is changed to take an `Alignment` which encodes the non-null constraint needed for `Unique` and allows us to do the construction safely.
Two internal-only APIs were added to let us avoid UB-checking in this hot code: `Layout::alignment` to get the `Alignment` type directly rather than as a `usize`, and `Unique::from_non_null` to create `Unique` in const context without a transmute.
Switch some rustc_on_unimplemented uses to diagnostic::on_unimplemented
The use on the SliceIndex impl appears unreachable, there is no mention of "vector indices" in any test output and I could not get it to show up in error messages.
remove remnants of const_box feature
This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch.
Closes https://github.com/rust-lang/rust/issues/92521 by removing the feature it tracks.
r? ````@oli-obk````
document capacity for ZST as example
The main text already covers this, although it provides weaker guarantees, but I think an example in the right spot does not hurt. Fixes#80747
Fix Ptr inconsistency in {Rc,Arc}
### PR Description
This pr aims to address the problem discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Inconsistency.20in.20.7BRc.2CArc.7D's.20ptr.20requirements/with/504259637).
### Problem Clarification
As this post presents, the `{Rc, Arc}::{in/de-crement_strong_count_/in}` do not limit the layout of the memory that `ptr` points to, while internally `Rc::from_raw_in` is called directly.
UB doesn't just appear when the strong count is decremented to zero. Miri also detects the UB of `out-of-bounds pointer use` when increment strong count is called on a pointer with an incorrect layout(shown as below).
```rust
use std::rc::Rc;
#[repr(align(8))]
struct Aligned8(u64);
#[repr(align(16))]
struct Aligned16(u64);
fn main() {
let rc: Rc<Aligned8> = Rc::new(Aligned8(42));
let raw_ptr = Rc::into_raw(rc);
unsafe {
Rc::increment_strong_count(raw_ptr as *const Aligned16);
}
}
```
Miri output:
```
error: Undefined Behavior: out-of-bounds pointer use: expected a pointer to 32 bytes of memory, but got alloc954 which is only 24 bytes from the end of the allocation
```
