The unsafe code can be justified within range_search, as it makes sure to not
overlap the returned references, but from the callers perspective it's an
entirely safe algorithm and there's no need for the caller to know about the
duplication.
Rollup of 5 pull requests
Successful merges:
- #71235 (Tweak `'static` suggestion code)
- #71318 (miri-unleash tests: ensure they fire even with 'allow(const_err)')
- #71428 (Let compiletest recognize gdb 10.x)
- #71475 (Miri Frame: use mir::Location to represent position in function)
- #71476 (more compact way to adjust test sizes for Miri)
Failed merges:
r? @ghost
Miri Frame: use mir::Location to represent position in function
I only recently learned that `Location` exists, and it seems to perfectly fit what Miri needs to represent which statement we are currently executing. :)
r? @ecstatic-morse
Let compiletest recognize gdb 10.x
git gdb has moved to version 10. My build prints this as its
--version:
GNU gdb (GDB) 10.0.50.20200420-git
Unfortunately this conflicts with this comment in compiletest:
// We limit major to 1 digit, otherwise, on openSUSE, we parse the openSUSE version
This patch changes the version parsing to follow the GNU coding
standard, which accounts for both the openSUSE case as well as
handling gdb 10.
My debuginfo test run now says:
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 10000050
... where previously it failed to find that gdb 10 had rust support.
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.
