-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add rustc
style errors for manifest parsing
#13172
Conversation
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
8a0c58a
to
31b833d
Compare
src/cargo/util/toml/mod.rs
Outdated
// Add back the new line that was stripped by `.lines()` | ||
if line_count > line + 1 { | ||
source.push('\n'); | ||
// If we are trying to highlight past the end of the file, add a | ||
// placeholder character to the end of the line. | ||
} else if span.end >= source.len() - 1 { | ||
source.push('∅'); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- This should be in annotate-snippets, not cargo
- The
'\n'
should be"\\n"
so it gets rendered - These should be Dimmed to indicate they aren't literal text
- These should only show up when they are being highlighted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not clear why the ∅
is being added, can you say more about the motivation there? I'm a little concerned about any potential confusion if users are not familiar with what that symbol means. I don't think rustc typically displays errors like that, and I think it is reasonably clear without a special character. For example:
error: this file contains an unclosed delimiter
--> src/main.rs:4:10
|
4 | fn x() {
| - ^
| |
| unclosed delimiter
or
error: expected one of `->`, `where`, or `{`, found `<eof>`
--> src/main.rs:4:9
|
4 | fn main()
| ^ expected one of `->`, `where`, or `{`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to find the conversation around invisible characters but it is a bit buried.
I think an aspect is that TOML is newline sensitive, unlike Rust, which elevates the importance of invisible characters and makes the chance of an error more frequent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed cargo
's ability to render invisible characters, as it is something that should be discussed in another issue
☔ The latest upstream changes (presumably #13166) made this pull request unmergeable. Please resolve the merge conflicts. |
This PR probably isn't the best place to have a broader discussion, but I was wondering about what the longer-term higher-level design approach will be with this. Some questions I have:
I'm happy to have a sync discussion sometime if that would be a better way to discuss the design ideas. |
For myself, I see this PR as picking the smallest subsection of cargo to allow us to start introducing rustc-style diagnostics and most larger discussions (how to spread this pattern to other parts of the code, json output) would be handled in incremental steps on top. I'm willing to accept some level of hacks ( The rough roadmap I see is
At this point, depending on priorities, we can better evaluate
|
31b833d
to
e7d43d7
Compare
e7d43d7
to
7a4baec
Compare
r? @epage |
0186fd2
to
0d62ae2
Compare
@bors r+ |
feat: Add `rustc` style errors for manifest parsing #12235 is tracking user control over warnings. One part of that is making `cargo`'s diagnostic system output messages in the style of `rustc`. To make it so that `cargo` doesn't have to manage a formatter and renderer, I decided to use [`annotate-snippets`](https://crates.io/crates/annotate-snippets), which matches `rustc`'s style well (at one time it was meant to be the formatted for `rustc`). To get this work kicked off, it was suggested to me that we should start with styling manifest parsing errors, and that is what his PR does. What manifest parsing errors look like after this change: ![image](https://github.com/rust-lang/cargo/assets/23045215/0eb388b9-8d72-48ad-84a9-585160995078) --- Note: `cargo` does not currently match `rustc` in color (#12740), `rustc` specifies their colors [here](https://github.com/rust-lang/rust/blob/740cea81d6e34fc03c4495890e29f1c5ecb40b96/compiler/rustc_errors/src/lib.rs#L1755-L1768) and [here](https://github.com/rust-lang/rust/blob/740cea81d6e34fc03c4495890e29f1c5ecb40b96/compiler/rustc_errors/src/emitter.rs#L2689-L2723). I used `annotate-snippets` default colors which match what `rustc` currently uses for colors. I did this as a stopgap while I work to unify the colors used between `rustc` and `cargo`. --- Note: the error messages come directly from `toml` and can be quite long. It would be nice if we could put some of the message below the highlight but this would require changes to `toml`. Example: ``` error: invalid type: integer `3` --> Cargo.toml:7:7 | 7 | bar = 3 | ^ expected a version string like "0.9.8" or a detailed dependency like { version = "0.9.8" } | ```
💥 Test timed out |
@bors retry macos never started |
☀️ Test successful - checks-actions |
Update cargo 8 commits in 3e428a38a34e820a461d2cc082e726d3bda71bcb..84976cd699f4aea56cb3a90ce3eedeed9e20d5a5 2024-01-09 20:46:36 +0000 to 2024-01-12 15:55:43 +0000 - fix(resolver): do not panic when sorting empty summaries (rust-lang/cargo#13287) - Implementation of shallow libgit2 fetches behind an unstable flag (rust-lang/cargo#13252) - Add documentation entry for unstable `--output-format` flag (rust-lang/cargo#13284) - doc: add `public` info in `cargo-add` man page. (rust-lang/cargo#13272) - More docs on prerelease compat (rust-lang/cargo#13286) - Add unstable `--output-format` option to `cargo rustdoc` (rust-lang/cargo#12252) - feat: Add `rustc` style errors for manifest parsing (rust-lang/cargo#13172) - Document why `du` function uses mutex (rust-lang/cargo#13273) r? ghost
The fix was backported to 1.77 (rust-lang#13393) which is when it got introduced (rust-lang#13172).
docs(changelog): Slight cleanup ### What does this PR try to resolve? For strip, I felt the nuance of where this change applies isn't as obvious and might give people the wrong impression, so I tried to make that front and center. For the panic, the fix was backported to 1.77 (#13393) which is when it got introduced (#13172). ### How should we test and review this PR? ### Additional information
The fix was backported to 1.77 (rust-lang#13393) which is when it got introduced (rust-lang#13172).
The fix was backported to 1.77 (rust-lang#13393) which is when it got introduced (rust-lang#13172).
#12235 is tracking user control over warnings. One part of that is making
cargo
's diagnostic system output messages in the style ofrustc
. To make it so thatcargo
doesn't have to manage a formatter and renderer, I decided to useannotate-snippets
, which matchesrustc
's style well (at one time it was meant to be the formatted forrustc
).To get this work kicked off, it was suggested to me that we should start with styling manifest parsing errors, and that is what his PR does.
What manifest parsing errors look like after this change:
Note:
cargo
does not currently matchrustc
in color (#12740),rustc
specifies their colors here and here. I usedannotate-snippets
default colors which match whatrustc
currently uses for colors. I did this as a stopgap while I work to unify the colors used betweenrustc
andcargo
.Note: the error messages come directly from
toml
and can be quite long. It would be nice if we could put some of the message below the highlight but this would require changes totoml
.Example: