Improve the documentation of atomic::fence
Attempt to "fix" two flaws of the current documentation:
1. The over-emphasis of fence - fence synchronization, relegating atomic - fence and fence - atomic synchronization to second fiddle.
2. The lack of explanation as to how to properly perform atomic - fence and fence - atomic synchronization.
It does so by first making it clear that there are 3 different ways to use an atomic fence, then presenting a full example for each usecase, noting the particular position of the fence with regard to the atomic operation, and rounding up with generic notes.
Attempt to "fix" two flaws of the current documentation:
1. The over-emphasis of fence - fence synchronization, relegating
atomic - fence and fence - atomic synchronization to second fiddle.
2. The lack of explanation as to how to properly perform atomic - fence
and fence - atomic synchronization.
It does so by first making it clear that there are 3 different ways to
use an atomic fence, then presenting a full example for each usecase,
noting the particular position of the fence with regard to the atomic
operation, and rounding up with generic notes.
Fix link in c_longlong documentation
Ran across this mistake when reading [the documentation](https://doc.rust-lang.org/std/ffi/type.c_longlong.html). I went through the other `.md` files in this directory and didn't spot any other errors.
**I did not check the output of this change** - I couldn't figure out how to get `cargo doc` to work and I figured it's not worth the distraction. It can't really go wrong, can it?
add note to `lines` docs about empty str behavior
This pull request adds a short note to the documentation for `str::lines` that describes the behavior of the resulting iterator when called on an empty string. I tripped over this a few days ago because I thought (incorrectly) that the iterator would return a single line with an empty string. I don't doubt that the actual behavior (return no lines) is the correct behavior, but in the absence of explicit documentation describing it, I came to the wrong conclusion about it and maybe others will too. If this is so obvious as to be not worth including, I'm happy to withdraw the pull request! Thanks for taking a look.
use funnel shift as fallback impl for rotating shifts
That lets us remove this gnarly implementation from Miri and const-eval.
However, `rotate_left`/`rotate_right` are stable as const fn, so to do this we have to `rustc_allow_const_fn_unstable` a bunch of const trait stuff. Is that a bad idea? Cc `@oli-obk` `@fee1-dead`
tweak primitive reference docs
This is a docs-only change for primitive reference.
I noticed a typo ("safe to use at type `T`") and fixed it to read "safe to use *as* type `T`".
While reading over the whole page, I also noticed another sentence that was hard to read. I tried to improve it: feel free to comment on the wisdom of this change...
Stabilize vec_into_raw_parts
This stabilizes `Vec::into_raw_parts()` and `String::into_raw_parts()` per FCP in https://github.com/rust-lang/rust/issues/65816#issuecomment-3517630971. While this _does not_ stabilize `Vec::into_parts()`, I fixed up the examples that said they were waiting for `vec_into_raw_parts`. As `Vec::from_parts()` and `Vec::into_parts()` are covered by the same feature `box_vec_non_null`, any doctest that uses `Vec::from_parts()` can also use `Vec::into_parts()` (and same for allocator-aware versions).
Closesrust-lang/rust#65816
``@rustbot`` modify labels: +T-libs-api
Remove `rustc_inherit_overflow_checks` from `position()` in slice iterators
This method implementation can never cause an overflow, since `i` can never go over the slice's length.
Expose fmt::Arguments::from_str as unstable.
Now that https://github.com/rust-lang/rust/pull/148789 is merged, we can have a fmt::Arguments::from_str. I don't know if we want to commit to always having an implementation that allows for this, but we can expose it as unstable for now so we can play with it.
Tracking issue: https://github.com/rust-lang/rust/issues/148905
CStr docs: Fix CStr vs &CStr confusion
The CStr documentation used to say things about CStr that are only true for &CStr.
Also, it's the bytes that are being borrowed, not the reference. One could say that it's the reference that is doing the borrowing, rather than being borrowed.
The CStr docs used to say things about CStr that are only true for &CStr.
Also, it's the bytes that are being borrowed, not the reference. One could say that it's the reference that is doing the borrowing, rather than being borrowed.
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to https://github.com/rust-lang/rust/issues/81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
Matthias Krüger