Document unsafety in core::{panicking, alloc::layout, hint, iter::adapters::zip}
Helps with #66219.
r? @Mark-Simulacrum do you want to continue reading safety comments? :D
Add leading 0x to offset in Debug fmt of Pointer
Currently the `Debug` format for `Pointer` prints its offset in hexadecimal, for example, `alloc38657819+e2` or `alloc35122748+64`. This PR adds a leading `0x` to the offset, in order to make it apparent that it is indeed a hexadecimal number. This came up during discussion of rust-lang/miri#1354. r? @RalfJung
Stabilize UNICODE_VERSION (feature unicode_version)
Tracking issue: #49726
r? @sfackler
#71020 changed the definition of `UNICODE_VERSION` just yesterday from a struct to a tuple. Maybe you want to wait some more before stabilizing this constant, on the other hand this is a very small and simple addition.
CC @behnam @SimonSapin @Serentty
Document unsafety in core::{option, hash}
Helps with #66219.
I think that the part that will need reviewing the most is the `hash/sip.rs` file.
r? @LukasKalbertodt (or someone else from the libs team)
Make the `structural_match` error diagnostic for const generics clearer
The previous diagnostic caused confusion (https://github.com/rust-lang/rust/issues/70790), so this changes the message to be closer to the message for using non-`structural_match` constants in patterns, explicitly mentioning `#[derive(PartialEq, Eq)]`.
Fixes https://github.com/rust-lang/rust/issues/70790.
r? @estebank
Fix doc links
This fixes a few doc links which were causing `cargo doc` to fail when using `--document-private-items --document-hidden-items` on libstd. Most of the fixes are just escaping '[' and ']' characters in doc comments, and one change actually fixes a doc link.
Only use read_unaligned in transmute_copy if necessary
I've noticed that this causes LLVM to generate poor code on targets that don't support unaligned memory accesses.
Check code blocks tags
Fixes#71347.
Explanations here: I realized recently that it was a common issue to confuse/misspell tags on code blocks. This is actually quite a big issue since it generally ends up in a code blocks being ignored since it's not being considered as a rust one. With this new warning, users will at least be notified about it.
PS: some improvements can be done on the error rendering but considering how big the PR already is, I think it's better to do it afterwards.
r? @ollie27
cc @rust-lang/rustdoc
Don't fuse Chain in its second iterator
Only the "first" iterator is actually set `None` when exhausted,
depending on whether you iterate forward or backward. This restores
behavior similar to the former `ChainState`, where it would transition
from `Both` to `Front`/`Back` and only continue from that side.
However, if you mix directions, then this may still set both sides to
`None`, totally fusing the iterator.
Fixes#71375
r? @scottmcm
Confusing suggestion on incorrect closing `}`
Compiler returns
```
error: unexpected closing delimiter: `}`
--> main.rs:20:1
|
9 | ErrorHandled::Reported => {}
| -- this block is empty, you might have not meant to close it temp
...
20 | }
| ^ unexpected closing delimiter
error: aborting due to previous error
```
This was needed by an early version of dataflow-based const
qualification where `QualifCursor` needed to return a full `BitSet` with
the current state.