Suggest installing rust-src when standard library source is unavailable - #158191
Suggest installing rust-src when standard library source is unavailable#158191sladyn98 wants to merge 1 commit into
rust-src when standard library source is unavailable#158191Conversation
|
cc @Muscraft |
|
r? @tiif rustbot has assigned @tiif. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
r? @estebank |
rust-src when standard library source is unavail…rust-src when standard library source is unavailable
…able When a diagnostic points into the standard library but its source isn't available locally (e.g. a rustup toolchain without the `rust-src` component), the emitter can only print the bare remapped path with no snippet. Emit a one-time `help` suggesting `rustup component add rust-src` so the next build can show the source. The hint is shown at most once per compilation (tracked with an `AtomicBool` on the emitter) and only for remapped std paths. It is added to both the primary and child-note fallbacks, since std spans usually appear in child "required by a bound in `core::...`" notes.
487bec6 to
55b1daf
Compare
|
@estebank I think we are good to merge this ? |
|
@estebank Any updates on this ? |
|
@bors r+ |
…t, r=estebank
Suggest installing `rust-src` when standard library source is unavailable
### Why
A lot of diagnostics point at a span *inside* the standard library e.g. `required by a bound in `std::iter::Iterator::sum``, or `JoinHandle::join takes ownership of the receiver`. For toolchains installed via `rustup` std is shipped with its paths remapped to `/rustc/<hash>/library/...` and the source itself is **not** included unless the `rust-src` component is installed.
So when an error references std, rustc tries to render that span, can't find the source on disk, and falls back to printing just the bare remapped path with no code:
```
error[E0277]: a value of type String cannot be made by summing an iterator ...
--> src/main.rs:2:20
...
note: required by a bound in std::iter::Iterator::sum
--> /rustc/<hash>/library/core/src/iter/traits/iterator.rs:3669:4
```
For the user this is a dead end: the path doesn't exist locally, there's no surrounding code. It *is* fixable: `rustup component add rust-src` makes the source available, after which the same diagnostic renders the real std snippet. But that capability is
invisible. This PR closes that discoverability gap by suggesting it at exactly the moment it would help.
Closes rust-lang#156402
Rollup of 5 pull requests Successful merges: - #158191 (Suggest installing `rust-src` when standard library source is unavailable) - #162122 (Put manual calls of Enzyme intrinsics behind a feature gate) - #162553 (Revert "Skip rustc book on i686") - #162562 (Add regression test for higher-ranked fn pointer trait impl mismatch errors) - #162518 (Add a revision for previously fixed solver issue)
This comment has been minimized.
This comment has been minimized.
Suggest installing `rust-src` when standard library source is unavailable
### Why
A lot of diagnostics point at a span *inside* the standard library e.g. `required by a bound in `std::iter::Iterator::sum``, or `JoinHandle::join takes ownership of the receiver`. For toolchains installed via `rustup` std is shipped with its paths remapped to `/rustc/<hash>/library/...` and the source itself is **not** included unless the `rust-src` component is installed.
So when an error references std, rustc tries to render that span, can't find the source on disk, and falls back to printing just the bare remapped path with no code:
```
error[E0277]: a value of type String cannot be made by summing an iterator ...
--> src/main.rs:2:20
...
note: required by a bound in std::iter::Iterator::sum
--> /rustc/<hash>/library/core/src/iter/traits/iterator.rs:3669:4
```
For the user this is a dead end: the path doesn't exist locally, there's no surrounding code. It *is* fixable: `rustup component add rust-src` makes the source available, after which the same diagnostic renders the real std snippet. But that capability is
invisible. This PR closes that discoverability gap by suggesting it at exactly the moment it would help.
Closes #156402
|
💔 Test for 8a723e4 failed: CI. Failed job:
|
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
@sladyn98 My apologies for the long delay. I was traveling for an extended period and I've only caught up with pings recently. It seems like you might have rebase on top of a more recent r=me once that is addressed. Thank you for working on this! |
Why
A lot of diagnostics point at a span inside the standard library e.g.
required by a bound instd::iter::Iterator::sum``, orJoinHandle::join takes ownership of the receiver. For toolchains installed via `rustup` std is shipped with its paths remapped to `/rustc//library/...` and the source itself is not included unless the `rust-src` component is installed.So when an error references std, rustc tries to render that span, can't find the source on disk, and falls back to printing just the bare remapped path with no code:
For the user this is a dead end: the path doesn't exist locally, there's no surrounding code. It is fixable:
rustup component add rust-srcmakes the source available, after which the same diagnostic renders the real std snippet. But that capability isinvisible. This PR closes that discoverability gap by suggesting it at exactly the moment it would help.
Closes #156402