Rollup of 6 pull requests
Successful merges:
- #101142 (Improve HIR stats)
- #101367 (Suggest `{Option,Result}::{copied,clone}()` to satisfy type mismatch)
- #101391 (more clippy::perf fixes)
- #101409 (Don't fire `rust_2021_incompatible_closure_captures` in `edition = 2021` crates)
- #101420 (Fix `hir::Local` doc to match with the variable name used: `init`)
- #101429 (Don't suggest reborrow if usage is inside a closure)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't suggest reborrow if usage is inside a closure
I can't think of why we would ever be able to *successfully* suggest a mutable reborrow `&mut *` due to a move happening due to a closure, so just suppress it.
Fixes#101119
Suggest `{Option,Result}::{copied,clone}()` to satisfy type mismatch
Fixes#100699, but in the opposite direction (instead of suggesting to fix the signature, it fixes the body)
proc_macro/bridge: use the cross-thread executor for nested proc-macros
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with `@eddyb,` we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? `@eddyb`
Make `const_eval_select` a real intrinsic
This fixes issues where `track_caller` functions do not have nice panic
messages anymore when there is a call to the function, and uses the
MIR system to replace the call instead of dispatching via lang items.
Fixes#100696.
Make `ReentrantMutex` movable and `const`
As `MovableMutex` is now `const`, it can be used to simplify the implementation and interface of the internal reentrant mutex type. Consequently, the standard error stream does not need to be wrapped in `OnceLock` and `OnceLock::get_or_init_pin()` can be removed.
Implement internal `IsZero` for Wrapping and Saturating for `Vec` optimizations
This implements the `IsZero` trait for the `Wrapping` and `Saturating` types so that users of these types can get the improved performance from the specialization of creating a `Vec` from a single element repeated when it has a zero bit pattern (example `vec![0_i32; 500]`, or after this PR `vec![Wrapping(0_i32); 500]`)
CC #60978
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with @eddyb, we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? @eddyb
rustdoc: remove redundant mobile-sized `.source nav:not(.sidebar).sub`
It's redundant because there's already a selector `.source nav.sub` with exactly the same margin-left at [line 796].
[line 796]: 84f0c3f79a/src/librustdoc/html/static/css/rustdoc.css (L796)
This selector was added in 1e98fb1027, along with an identical desktop selector, but that desktop selector was removed in 6a5f8b1aef as part of a larger simplification.
Forbid mixing `System` with direct sytem allocator calls
e.g. [on windows](dec689432f/library/std/src/sys/windows/alloc.rs (L129-L178)), trying to mix `System::alloc` and `HeapFree` will not work because of the extra work done to serve higher alignments.
updated description of File struct in std::fs
I've seen several folks confused by the description of `std::fs::File` as "A reference to an open file on the filesystem." Apparently the word `reference` is sometimes taken to mean a Rust `&` reference, leading to confusion. Here's a recent representative [Reddit thread](https://www.reddit.com/r/rust/comments/x4k0lv/comment/imxu7v2/?utm_source=share&utm_medium=web2x&context=3), but I've seen this before as well.
This patch changes the description to "An object providing access to an open file on the filesystem." Hopefully this is clearer.
Fix internal doc link
The doc link from `DedupSortedIter` to `BTreeMap::bulk_build_from_sorted_iter` was broken when building internal documentation,
This prevented me from building internal documentation locally:
```
R:\Rust\rust> $env:RUSTDOCFLAGS="--document-private-items"
R:\Rust\rust> x doc library/std --open --stage 0
Building rustbuild
Compiling bootstrap v0.0.0 (R:\Rust\rust\src\bootstrap)
Finished dev [unoptimized] target(s) in 3.15s
Documenting stage0 std (x86_64-pc-windows-msvc)
Documenting core v0.0.0 (R:\Rust\rust\library\core)
Finished release [optimized] target(s) in 36.42s
Checking core v0.0.0 (R:\Rust\rust\library\core)
Checking rustc-std-workspace-core v1.99.0 (R:\Rust\rust\library\rustc-std-workspace-core)
Checking compiler_builtins v0.1.79
Documenting alloc v0.0.0 (R:\Rust\rust\library\alloc)
error: unresolved link to `BTreeMap::bulk_build_from_sorted_iter`
--> library\alloc\src\collections\btree\dedup_sorted_iter.rs:6:15
|
6 | /// Used by [`BTreeMap::bulk_build_from_sorted_iter`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `BTreeMap` in scope
|
= note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
error: could not document `alloc`
```
safe transmute: use `Assume` struct to provide analysis options
This task was left as a TODO in #92268; resolving it brings [`BikeshedIntrinsicFrom`](https://doc.rust-lang.org/nightly/core/mem/trait.BikeshedIntrinsicFrom.html) more in line with the API defined in [MCP411](https://github.com/rust-lang/compiler-team/issues/411).
**Before:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<
Src,
Context,
const ASSUME_ALIGNMENT: bool,
const ASSUME_LIFETIMES: bool,
const ASSUME_VALIDITY: bool,
const ASSUME_VISIBILITY: bool,
> where
Src: ?Sized,
{}
```
**After:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<Src, Context, const ASSUME: Assume = { Assume::NOTHING }>
where
Src: ?Sized,
{}
```
`Assume::visibility` has also been renamed to `Assume::safety`, as library safety invariants are what's actually being assumed; visibility is just the mechanism by which it is currently checked (and that may change).
r? `@oli-obk`
---
Related:
- https://github.com/rust-lang/compiler-team/issues/411
- https://github.com/rust-lang/rust/issues/99571
