docs: Fix typo in std/src/thready/scoped.rs
# Fix typo in std/src/thread/scoped.rs
## Why this pr
This PR fixes the typo mentioned in rust-lang/rust#155275.
I know this was originally fixed in rust-lang/rust#155325 and then in rust-lang/rust#155328.
But since the first issue was closed due to some ai slop and the second one was closed because the first one was already opened, it seems to me that this PR is still needed.
## What this pr does
This PR "just" fixes a typo inside the `std/src/thread/scoped.rs` file
Changing the comment from this:
```
/// borrow non-`'static` data from the outside the scope. See [`scope`] for
/// details.
```
to this:
```
/// borrow non-`'static` data from outside the scope. See [`scope`] for
/// details.
```
rustdoc: Fix `redundant_explicit_links` incorrectly firing (or not firing) under certain scenarios
Hi! I found some issues with the `rustdoc::redundant_explicit_links` lint while working on a personal project.
- After skipping a link that contains inline markups, the lint would incorrectly skip all the remaining links.
For example, with the following snippet, the lint is fired for `[Option][Option]`, but not `[Result][Result]`:
```rs
//! [Option][Option]
//! [**u8**][u8] (skipped)
//! [Result][Result]
```
Happening because of a `?` causing a loop to bail early:
https://github.com/rust-lang/rust/blob/a4a37ed163a6c1d227b58047d91457589c611cf8/src/librustdoc/passes/lint/redundant_explicit_links.rs#L107
- The lint is fired for links that specify titles (like `[link](link "title")`), except that wouldn't be applicable because it's not possible to specify a title without there also being an explicit target. For example:
```
error: redundant explicit link target
--> <anon>:5:12
|
5 | /// [drop](drop "This function is not magic")
| ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ explicit target is redundant
| |
| because label contains path that resolves to same destination
|
= note: when a link's destination is not specified,
the label is used to resolve intra-doc links
help: remove explicit link target
|
5 - /// [drop](drop "This function is not magic")
5 + /// [drop]
|
```
These are found as of:
```
rustdoc 1.97.0-nightly (1b8f2e46e 2026-04-17)
binary: rustdoc
commit-hash: 1b8f2e46e1
commit-date: 2026-04-17
host: aarch64-apple-darwin
release: 1.97.0-nightly
LLVM version: 22.1.2
```
(Note: I ran `./x test tests/rustdoc-ui` locally, but not `./x tidy` due to my slow internet. There was an unrelated failed test at `tests/rustdoc-ui/ice-bug-report-url.rs` which I'm not sure about)
Fix ICE in borrowck mutability suggestion with multi-byte ref sigil
Fixesrust-lang/rust#139089
Similarly to rust-lang/rust#155068, this is another instance where span arithmetic did not account for multi-byte characters. (Note that the ampersand in the test is full-width)
This change also results in correcting some inappropriate suggestions.
Fix misleading "borrowed data escapes outside of function" diagnostic
Fixesrust-lang/rust#154350
Fall back to `report_general_error()` when `fr_name_and_span` is `None` in function items, since the "escaping data" framing is only appropriate for closures capturing outside variables.
Move recursion out of `MatchPairTree::for_pattern` helpers
The helper functions now just iterate over the relevant subpatterns, while leaving recursion up to the main function.
This avoids passing parameters that were only used for recursive plumbing, and consolidates all recursive calls into `for_pattern` itself, which should make it easier to experiment with changes to the recursive structure.
There should be no change to compiler behaviour.
`impl Default for RepeatN`
This creates an empty iterator, like `repeat_n(value, 0)` but without
needing any such value at hand. There's precedent in many other
iterators that the `Default` is empty, like `slice::Iter`.
I found myself wanting this for rayon's `RepeatN` as it lowers to a
sequential iterator [here][1]. Since rayon is also optimizing to avoid
extra clones, it may end up with parallel splits that have count 0 and
no item value. Calling `std::iter::repeat_n(x, 0)` just drops that
value, but there's no way to construct the same result without a value
yet. This would be straightforward with an empty `Default`.
[1]: https://github.com/rayon-rs/rayon/blob/ae07384e3e0b238cea89f0c14891f351c65a5cee/src/iter/repeat.rs#L201-L202
r? libs-api (insta-stable)
Add Sized supertrait for CoerceUnsized and DispatchFromDyn
This is part of rust-lang/rust#149094. I did not include `Receiver` because I think it is correct to allow non-sized receivers.
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#154781 (Fix attribute order implementation)
- rust-lang/rust#155242 (resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively)
- rust-lang/rust#149614 (Use `MaybeDangling` in `std`)
- rust-lang/rust#153178 (Add `TryFromIntError::kind` method and `IntErrorKind::NotAPowerOfTwo` variant)
- rust-lang/rust#155049 (Documenting the case of `Weak::upgrade` returning `None` when the value behind the reference is missing)
Failed merges:
- rust-lang/rust#155308 (Make `OnDuplicate::Error` the default for attributes)
Documenting the case of `Weak::upgrade` returning `None` when the value behind the reference is missing
Adds a clause to the documentation of `Weak` for `Arc` which was discussed in rust-lang/rust#154936.
Adds the same clause to the documentation of `Weak` for `Rc`, because the behavior is the same.
Add `TryFromIntError::kind` method and `IntErrorKind::NotAPowerOfTwo` variant
- ACP: rust-lang/libs-team#746
- Tracking issue: rust-lang/rust#153978
This pull request adds `kind` method to [`TryFromIntError`](https://doc.rust-lang.org/core/num/struct.TryFromIntError.html), which outputs the detailed cause of converting an integer failing.
This is primarily intended for use in cases where there are multiple causes for failure, such as converting from a large signed integer type to a small signed integer type.
At the moment, this method returns [`&IntErrorKind`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html). This type implements the `Copy` trait and could return `IntErrorKind`, but returns a reference to align with the behavior of [`ParseIntError::kind`](https://doc.rust-lang.org/core/num/struct.ParseIntError.html#method.kind). If it is not necessary to align the behavior of `TryFromIntError::kind` with `ParseIntError::kind`, I'll change this method to return `IntErrorKind`.
Before this pull request, `IntErrorKind` was only used by [`ParseIntError`](https://doc.rust-lang.org/core/num/struct.ParseIntError.html), but I changed it to be used by `TryFromIntError` as well, so I updated `IntErrorKind`'s documentation.
[`impl TryFrom<usize> for Alignment`](https://doc.rust-lang.org/std/ptr/struct.Alignment.html#impl-TryFrom%3Cusize%3E-for-Alignment) returns `TryFromIntError` as an error if the given value is not a power of two. However, `IntErrorKind` does not have a variant that represents this. So I added the variant `NotAPowerOfTwo` to represent this. For this variant to stabilize, both `try_from_int_error_kind` and `ptr_alignment_type` features must be stabilized.
resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively
Right now both `LocalModule` and `ExternModule` refer to the same `ModuleData`, but the module data for local and extern modules can potentially be made quite different, and we can specialize name lookup for both cases as an optimization.
Declaration creation for local and external modules was already specialized as a part of the parallel import resolution work (see `define_local` and `define_extern`, rust-lang/rust#145108 and previous PRs), because they have different properties with regards to ownership and synchronization.
Fix attribute order implementation
The implementation in https://github.com/rust-lang/rust/pull/153041 contained a mistake :c
I swapped the place where the error message was on, but did not change any code for which attribute was also selected, which explains the empty crater results.
**Interestingly, the original code is broken too, before https://github.com/rust-lang/rust/pull/153041 it always took the last attribute, regardless of what the `AttributeOrder` actually was...**
Let's first see crater results before making a decision
TODO for this PR: Make better tests for this
delegation: fix def path hash collision, add per parent disambiguators
This PR addresses the following delegation issues:
- It fixesrust-lang/rust#153410 when generating new `DefId`s for generic parameters by ~saving `DisambiguatorState`s from resolve stage and using them at AST -> HIR lowering~ introducing per owner disambiguators and transferring them to AST -> HIR lowering stage
- ~Next it fixes the ICE which is connected to using `DUMMY_SP` in delegation code, which was found during previous fix~
- ~Finally, after those fixes the rust-lang/rust#143498 is also fixed, only bugs with propagating synthetic generic params are left.~
Fixesrust-lang/rust#153410. Part of rust-lang/rust#118212.
r? @petrochenkov
compiletest: Remove the `//@ should-ice` directive
The `//@ should-ice` directive was only being used by one test, which can just as easily use the more general `//@ failure-status` directive instead.
All of the removed exit-code checks were redundant with other exit-code checks that are still present.
---
I have manually verified that `tests/incremental/delayed_span_bug.rs` fails if the failure-status directive is modified or removed.
Tweak how the "copy path" rustdoc button works to allow some accessibility tool to work with rustdoc
Fixes https://github.com/rust-lang/rust/issues/155032.
It's a bit better in term of "fragility" to retrieve this information: no need to parse text anymore, just to retrieve content. However it relies on HTML. I added extra tests to ensure it won't break without notice.
cc @Enyium
r? @lolbinarycat
Rearrange `rustc_ast_pretty`
`rustc_ast_pretty` has two modules, `pp::convenience` and `helpers`, that are small and silly. This PR eliminates them. Details in the individual commits.
r? @WaffleLapkin
tests/debuginfo/basic-stepping.rs: Remove FIXME related to ZSTs
We don't consider it a bug that users can't break on initialization of some non-zero sized types (see https://github.com/rust-lang/rust/pull/153941 and linked discussions), so it does not make sense to consider it a bug that users can't break on initialization of some zero-sized types.
Closesrust-lang/rust#97083
r? compiler (see https://github.com/rust-lang/rust/pull/155352)
ImproperCTypes: Move erasing_region_normalisation into helper function
This is "part 1/3 of 2/3 of 1/2" of the original pull request https://github.com/rust-lang/rust/pull/134697 (refactor plus overhaul of the ImproperCTypes family of lints)
(all pulls of this series of pulls are supersets of the previous pulls. If this pull is "too small" to be worth the effort, you can instead look at the next in the series)
This pull is a small internal change among the efforts to refactor the ImproperCTypes lints, by moving some "unwrapping" code (`cx.tcx.try_normalize_erasing_regions`) into a helper function.
r? petrochenkov
Make `convert_while_ascii` unsafe
`convert_while_ascii` assumes `convert` only returns ASCII to ensure the output remains valid UTF-8. This adds that requirement as a safety precondition.
changed the information provided by (mut x) to mut x (Fix 155030)
When trying to change a value without using mut in a for loop, the recommendation for this change is incorrect, so I am correcting it.
resolve: rust-lang/rust#155030
rustdoc: preserve `doc(cfg)` on locally re-exported type aliases
When a type alias is locally re-exported from a private module (an implicit inline), rustdoc drops its `cfg` attributes because it treats it like a standard un-inlined re-export. Since type aliases have no inner fields to carry the `cfg` badge (unlike structs or enums), the portability info is lost entirely.
This patch explicitly preserves the target's `cfg` metadata when the generated item is a `TypeAliasItem`, ensuring the portability badge renders correctly without breaking standard cross-crate re-export behavior.
Fixesrust-lang/rust#154921
Remove AttributeSafety from BUILTIN_ATTRIBUTES
Encodes the expected attribute safety in the attribute parsers, rather than in `BUILTIN_ATTRIBUTES`, with the goal of removing `BUILTIN_ATTRIBUTES` soon.
We can remove the old attribute safety logic already because unparsed attributes, just like the as of yet unparsed lint attributes, need to be safe.
r? @jdonszelmann (or @mejrs if you feel like doing it, since you are in T-compiler now 🎉)
Jacob Pratt