stable hashing: Remove unused field and add documentation.
This PR removes the `bytes_hashed` field from `StableHasher` which in the past has been used for collecting some statistics but has gone unused for quite a while (months at least) now.
The PR also tries to document some requirements for `HashStable` implementations that haven't been written down explicitly anywhere.
Fix intra-doc link resolution failure on re-exporting libstd
Currently, re-exporting libstd items as below will [occur a lot of failures](https://gist.github.com/taiki-e/e33e0e8631ef47f65a74a3b69f456366).
```rust
pub use std::*;
```
Until the underlying issue (#56922) fixed, we can fix that so they don't propagate to downstream crates.
Related: https://github.com/rust-lang/rust/pull/56941 (That PR fixed failures that occur when re-exporting from libcore to libstd.)
r? @QuietMisdreavus
Fix search sidebar width when no crate select is present
Fixes#60480.
I also fixed the box-shadow that seemed to have been kind of removed?
r? @QuietMisdreavus
stabilize core parts of MaybeUninit
and deprecate mem::uninitialized in the future (1.40.0). This is part of implementing https://github.com/rust-lang/rfcs/pull/1892.
Also expand the documentation a bit.
This type is currently primarily useful when dealing with partially initialized arrays. In libstd, it is used e.g. in `BTreeMap` (with some unstable APIs that however can all be replaced, less ergonomically, by stable ones). What we stabilize should also be enough for `SmallVec` (Cc @bluss).
Making this useful for structs requires https://github.com/rust-lang/rfcs/pull/2582 or a commitment that references to uninitialized data are not insta-UB.
Remove the unstable and deprecated mpsc_select
This removes macro `select!` and `std::sync::mpsc::{Handle, Select}`,
which were all unstable and have been deprecated since 1.32.
Closes#27800
r? @SimonSapin
Use `Symbol` even more
These patches simplify the code a bit (fewer conversions) and also speed things up a bit (fewer `with_interner` calls).
r? @petrochenkov
Rollup of 6 pull requests
Successful merges:
- #60590 (Test interaction of unions with non-zero/niche-filling optimization)
- #60745 (Perform constant propagation into terminators)
- #60895 (Enable thumbv7a-pc-windows-msvc target build end to end in rust/master)
- #60908 (Fix lints handling in rustdoc)
- #60960 (Stop using gensyms in HIR lowering)
- #60962 (Fix data types indication)
Failed merges:
r? @ghost
`LocalInternedString::intern(x)` is preferable to
`Symbol::intern(x).as_str()`, because the former involves one call to
`with_interner` while the latter involves two.
`InternedString::intern(x)` is preferable to
`Symbol::intern(x).as_interned_str()`, because the former involves one
call to `with_interner` while the latter involves two.
The case within InternedString::decode() is particularly hot, and this
change reduces the number of `with_interner` calls by up to 13%.
Fix data types indication
Fix the data types indication in basic examples of the Trait std::fmt::LowerExp and std::fmt::UpperExp.
Since there aren’t any type annotation on the let statement using the number 42.0, they are of type f64 according to The Book:
https://doc.rust-lang.org/book/ch03-02-data-types.html#floating-point-types
Stop using gensyms in HIR lowering
These names aren't ever handled by resolve, so there's no reason to
make them gensyms.
Diagnostics wanting to behave differently for these variables should
inspect either the `MatchSource`/`LocalSource` or the `Span`. All
current diagnostics appear to do this.
r? @petrochenkov
Fix lints handling in rustdoc
Part of #60664: now lints are handled just like any other lints you would setup in rustc. Still remains to handle `missing code examples` and `missing_docs` as part of the same group.
r? @oli-obk
Enable thumbv7a-pc-windows-msvc target build end to end in rust/master
With this PR, plus another commit cf98161da7, I'm able to build the target thumbv7a-pc-windows-msvc successfully, and I'm able to use the stage2 artifacts to build arm32 projects. The commit in compiler_builtins is in release 0.1.14, the current cargo.lock in rust master still uses 0.1.12, so I bumped the compiler_builtins version in cargo.lock to 0.1.15
The command I used to build rust
```
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc --verbose
```
**Changes**
1. update cargolock to use compiler_builtins 0.1.15
2. handle libunwind in libtest for thumv7a the same as what we have for aarch64
3. in llvm codegen add a field in CodegenContext to carry the arch, so later in create_msvc_imps function, the arch can be used to check against "x86", instead of 32 pointer width. Apparently Thumv7a is handled differently than x86.
**Background**
I'm from Microsoft working on enabling Azure IoTEdge on ARM32 Windows IoTCore, Azure IoTEdge has a component called IoTEdged written in rust as a NT service running on Windows, so we need to enable rust on thumbv7a in order to have full IoTEdge. My colleague had made some heavy lifting and we've been using our private toolchain to build IoTEdged in our devops pipeline, because at that time we cannot build thumbv7a target end to end successfully. This change is a followup to enable the end to end build for thumbv7a-pc-windows-msvc target.
**Next step**
I'll submit more changes to have this target built nightly in rust/master, to achieve the same availability for aarch64-pc-windows-msvc, indexed here https://rust-lang.github.io/rustup-components-history/aarch64-pc-windows-msvc.html and can be manually installed. **Please do share what takes to make this happen, is there a formal process I need to follow\?**
Perform constant propagation into terminators
Perform constant propagation into MIR `Assert` and `SwitchInt` `Terminator`s which in some cases allows them to be removed by the branch simplification pass.
r? @oli-obk
Test interaction of unions with non-zero/niche-filling optimization
Notably this nails down part of the behavior that MaybeUninit assumes, e.g. that a Option<MaybeUninit<&u8>> does not take advantage of non-zero optimization, and thus is a safe construct.
It also verifies the status quo: that even unions that could theoretically take advantage of niches don't. (relevant: https://github.com/rust-lang/rust/issues/36394)
Explicitly set height on rust logo <img> element in docs
The layout of the left side menu in docs reflows when navigating between pages because of missing height on the <img> element of rust logo.
Setting height='100' tells the browser to reserve that vertical space, leading to a less janky experience.
rustdoc: set the default edition when pre-parsing a doctest
Fixes https://github.com/rust-lang/rust/issues/59313 (possibly more? i think we've had issues with parsing edition-specific syntax in doctests at some point)
When handling a doctest, rustdoc needs to parse it beforehand, so that it can see whether it declares a `fn main` or `extern crate my_crate` explicitly. However, while doing this, rustdoc doesn't set the "default edition" used by the parser like the regular compilation runs do. This caused a problem when parsing a doctest with an `async move` block in it, since it was expecting the `move` keyword to start a closure, not a block.
This PR changes the `rustdoc::test::make_test` function to set the parser's default edition while looking for a main function and `extern crate` statement. However, to do this, `make_test` needs to know what edition to set. Since this is also used during the HTML rendering process (to make playground URLs), now the HTML renderer needs to know about the default edition. Upshot: rendering standalone markdown files can now accept a "default edition" for their doctests with the `--edition` flag! (I'm pretty sure i waffled around how to set that a long time ago when we first added the `--edition` flag... `>_>`)
I'm posting this before i stop for the night so that i can write this description while it's still in my head, but before this merges i want to make sure that (1) the `rustdoc-ui/failed-doctest-output` test still works (i expect it doesn't), and (2) i add a test with the sample from the linked issue.
Fix the data types indication in basic examples of the Trait std::fmt::LowerExp and std::fmt::UpperExp.
Since there aren’t any type annotation on the let statement using the number 42.0, they are of type f64 according to The Book:
https://doc.rust-lang.org/book/ch03-02-data-types.html#floating-point-types
Rollup of 8 pull requests
Successful merges:
- #60370 (Mark core::alloc::Layout::from_size_align_unchecked const)
- #60678 (Stabilize vecdeque_rotate)
- #60924 (Explain that ? converts the error type using From)
- #60931 (Use iter() for iterating arrays by slice)
- #60934 (Declare DefIndex with the newtype_index macro)
- #60943 (fix copy-paste typo in docs for ptr::read_volatile)
- #60945 (Simplify BufRead::fill_buf doc example using NLL)
- #60947 (Fix typos in docs of GlobalAlloc)
Failed merges:
r? @ghost
Simplify BufRead::fill_buf doc example using NLL
With non-lexical lifetimes, in this example it is no longer necessary to use a block to end the borrow early.
Use iter() for iterating arrays by slice
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
Mark core::alloc::Layout::from_size_align_unchecked const
Makes it possible (pending stabilization of #57563 (`const_fn`)) to rewrite code like
```rust
const BUFFER_SIZE: usize = 0x2000;
const BUFFER_ALIGN: usize = 0x1000;
fn foo() {
let layout = std::alloc::Layout::from_size_align(BUFFER_SIZE, BUFFER_ALIGN)
.unwrap();
let buffer = std::alloc::alloc(layout);
}
```
to
```rust
const BUFFER_LAYOUT: std::alloc::Layout = unsafe {
std::alloc::Layout::from_size_align_unchecked(0x2000, 0x1000)
};
fn foo() {
let buffer = std::alloc::alloc(BUFFER_LAYOUT);
}
```
which (although `unsafe` is used) looks somewhat cleaner and is easier to read.
