Rollup of 9 pull requests
Successful merges:
- #90507 (Suggest `extern crate alloc` when using undeclared module `alloc`)
- #90530 (Simplify js tester a bit)
- #90533 (Add note about x86 instruction prefixes in asm! to unstable book)
- #90537 (Update aarch64 `target_feature` list for LLVM 12.)
- #90544 (Demote metadata load warning to "info".)
- #90554 (Clean up some `-Z unstable-options` in tests.)
- #90556 (Add more text and examples to `carrying_{add|mul}`)
- #90563 (rustbot allow labels)
- #90571 (Fix missing bottom border for headings in sidebar)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustbot allow labels
`relnotes` was 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.
For `needs-fcp`, I think people should be able to help triage by observing that a change needs an FCP before we can apply it.
Clean up some `-Z unstable-options` in tests.
Several of these tests were for features that have been stabilized, or otherwise don't need `-Z unstable-options`.
Demote metadata load warning to "info".
There is a warn log message for whenever the crate loader fails to load metadata from a candidate file. I think this warning is too aggressive, as there are several situations where metadata information might not be found in a candidate file, which is normal. Also, this warning is somewhat confusing, and non-actionable in most cases for a user (most users will not know what it means).
If the crate loader ultimately does not find a valid crate, then an error will be reported (and hopefully #88368 will improve that error message).
If a rustc developer wants to debug a loader problem, they can still use `RUSTC_LOG=rustc_metadata=debug` and get the details.
There is more discussion of this particular warning at https://github.com/rust-lang/rust/issues/89795#issuecomment-940798190.
Fixes#90525
Update aarch64 `target_feature` list for LLVM 12.
Many of these feature are now available on all valid LLVM versions.
I've also added a few new ones to the list.
r? `@Amanieu`
Add note about x86 instruction prefixes in asm! to unstable book
Since rustc doesn't do the assembly parsing itself, it is unable to detect when inline assembly ends with an instruction prefix, which doesn't make sense since it would apply to instructions from the compiler. This fixes#82314 by mentioning that x86 instruction prefixes must not be used in inline assembly. AFAICT x86 is the only instruction set with instruction prefixes.
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`
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.
Since rustc doesn't do the assembly parsing itself, it is unable
to detect when inline assembly ends with an instruction prefix,
which doesn't make sense since it would apply to instructions from
the compiler. This fixes#82314 by mentioning that x86 instruction
prefixes must not be used in inline assembly.
Use apple-a14 as target CPU for aarch64-apple-darwin
After updating the minimum required LLVM version to 12 (#90175) we can use `apple-a14` as target CPU, because that CPU is similar in features to the Apple M1 (see [LLVM 13 source](b8016b626e/llvm/lib/Target/AArch64/AArch64.td (L1127))). Once the minimum required LLVM version is updated to 13 we can use `apple-m1` here.
Replace `std::os::raw::c_ssize_t` with `std::os::raw::c_ptrdiff_t`
The discussions in #88345 brought up that `ssize_t` is not actually the signed index type defined in stddef.h, but instead it's `ptrdiff_t`. It seems pretty clear that the use of `ssize_t` here was a mistake on my part, and that if we're going to bother having a isize-alike for FFI in `std::os::raw`, it should be `ptrdiff_t` and not `ssize_t`.
Anyway, both this and `c_size_t` are dubious in the face of the discussion in https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369, and any RFC/project-group/etc that handles those issues there should contend with these types in some manner, but that doesn't mean we shouldn't fix something wrong like this, even if it is unstable.
All that said, `size_t` is *vastly* more common in function signatures than either `ssize_t` or `ptrdiff_t`, so I'm going to update the tracking issue's list of unresolved questions to note that perhaps we only want `c_size_t` — I mostly added the signed version for symmetry, rather than to meet a need. (Given this, I'm also fine with modifying this patch to instead remove `c_ssize_t` without a replacement)
CC `@magicant` (who brought the issue up)
CC `@chorman0773` (who has a significantly firmer grasp on the minutae of the C standard than I do)
r? `@joshtriplett` (original reviewer, active in the discussions around this)
bors