Inspired by https://github.com/rust-lang/rust/pull/90521 , and by the
various `must_use` PRs; in all of those cases, the submitter of the PR
could know that `relnotes` applied, but couldn't apply it themselves.
update rustc_ast crate descriptions in documentation
I noticed this the other day and figured I'd suggest a refresh. It seems like a relic from the days of `libsyntax` that got missed as things were split out into separate crates, since the current documentation text references elements that were moved into their own respective crates (e.g. `rustc_parse`)
Implement `RefUnwindSafe` for `Rc<T>`
This PR implements `RefUnwindSafe` for `Rc<T>`, where `T: RefUnwindSafe`.
This impl was omitted by an apparent oversight. `Rc<T>` already implements `UnwindSafe`. `Arc<T>` implements both `UnwindSafe` and `RefUnwindSafe`. There is no reason why an `&Rc<T>` is any less unwind safe than a `Rc<T>` or an `&Arc<T>`, so this should be safe to add.
Resolves#45924.
Add beginner friendly lifetime elision hint to E0623
Address #90170
Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't.
Example:
```
error[E0623]: lifetime mismatch
--> $DIR/issue-90170-elision-mismatch.rs:2:35
|
LL | fn foo(slice_a: &mut [u8], slice_b: &mut [u8]) {
| --------- --------- these two types are declared with different lifetimes...
LL | core::mem::swap(&mut slice_a, &mut slice_b);
| ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here
|
= note: each elided lifetime in input position becomes a distinct lifetime
help: explicitly declare a lifetime and assign it to both
|
LL | fn foo<'a>(slice_a: &'a mut [u8], slice_b: &'a mut [u8]) {
| ++++ ++ ++
```
for
```rust
fn foo(slice_a: &mut [u8], slice_b: &mut [u8]) {
core::mem::swap(&mut slice_a, &mut slice_b);
}
```
rustdoc: Add `DocVisitor` and use it where possible
`DocFolder` allows transforming the docs, accomplished by making its methods take and return types by-value. However, several of the rustdoc `DocFolder` impls only *visit* the docs; they don't change anything. Passing around types by-value is thus unnecessary, confusing, and potentially inefficient for those impls.
`DocVisitor` is very similar to `DocFolder`, except that its methods take shared references and return nothing (i.e., the unit type). This should both be more efficient and make the code clearer.
There is an additional reason to add `DocVisitor`, too. As part of my cleanup of `external_traits`, I'm planning to add a `fn cache(&mut self) -> &mut Cache` method to `DocFolder` so that `external_traits` can be retrieved explicitly from the `Cache`, rather than implicitly via `Crate.external_traits` (which is an `Rc<RefCell<...>>`). However, some of the `DocFolder` impls that could be turned into `DocVisitor` impls only have a shared reference to the `Cache`, because they are used during rendering. (They have to access the `Cache` via `html::render::Context.shared.cache`, which involves an `Rc`.)
Since `DocVisitor` does not mutate any of the types it's visiting, its equivalent `cache()` method will only need a shared reference to the `Cache`, avoiding the problem described above.
r? `@GuillaumeGomez`
cc `@jyn514`
RawVec was previously exposed for compiler-internal use (libarena specifically) in 1acbb0a9350560d951359cc359361b87992a6f2b
Since it is unstable, doc-hidden and has no associated tracking issue it was never meant for public use. And since
it is no longer used outside alloc itself it can be made private again.
Also remove some functions that are dead due to lack of internal users.
Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't
Issue #90170
This also changes the tests introduced by the previous commits because of another rustc issue (#90258)
`addr_of!` grants mutable access, maybe?
The exact set of permissions granted when forming a raw reference is
currently undecided https://github.com/rust-lang/rust/issues/56604.
To avoid presupposing any particular outcome, adjust the const
qualification to be compatible with decision where raw reference
constructed from `addr_of!` grants mutable access.
Additionally, to avoid keeping `MaybeMutBorrowedLocals` in sync with
const qualification, remove it. It's no longer used.
`@rust-lang/wg-const-eval`
The exact set of permissions granted when forming a raw reference is
currently undecided https://github.com/rust-lang/rust/issues/56604.
To avoid presupposing any particular outcome, adjust the const
qualification to be compatible with decision where raw reference
constructed from `addr_of!` grants mutable access.
This is just replicating the previous algorithm, but taking advantage of the
bitset structures to optimize into tighter and better optimized loops.
Particularly advantageous on enormous MIR blocks, which are relatively rare in
practice.
