Skip to content
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

Print span info for errors #12810

Open
est31 opened this issue Oct 12, 2023 · 6 comments
Open

Print span info for errors #12810

est31 opened this issue Oct 12, 2023 · 6 comments
Assignees
Labels
A-diagnostics Area: Error and warning messages generated by Cargo itself. S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@est31
Copy link
Member

est31 commented Oct 12, 2023

Filing a new one as #6144 was closed as RLS specific, but the underlying issue exists with rust-analyzer as well. It also exists in my private "Konsole + Kate" workflow.

TLDR: Cargo should print span information for diagnostics, that is column and line numbers (plus file name) that are seen as relevant to the error or diagnostic. It can maybe also print snippets like rustc, but a good first step would be to have some span information at all.

Consider when you mistype a dependency in Cargo.toml: cargo gives an error that the dependency can't be found. But it does not point to the line. In many IDEs, when there is a string like Cargo.toml:15:0, a ctrl+click on that opens the editor at right that spot. This is very helpful for editor workflows.

Instead, one has to look for the "actionable spot" of the error manually. This is sub-optimal and could be improved.

Earlier issues:

@epage
Copy link
Contributor

epage commented Oct 12, 2023

You mention rust-analyzer and your own workflow combined with "printing" spans. Are you needing spans printed in human readable output or json? I'm assuming rust-analyzer would actually be the latter and is a larger step beyond the human readable side.

If this issue is meant to encompass rust-analyzer, it would likely be good to get someone from that project on this issue so we make sure we deliver the right thing.

As for a path for this, it would look roughly like

  • Someone is working on User control over cargo warnings #12235 which they expect to have spans and machine applicable support (cargo fix) as part of it
  • We then work to refactor the error side of things to be more like warnings (maybe leveraging Diagnostics) with cargo-running-rustc like behavior where we print the error immediately and then unwind the stack with a "operation failed" error
    • An extension of this is we can choose to make some errors not bail out immediately, allowing people to see what other errors come up
  • We re-work the errors, where possible, to include spans
  • We figure out the json format and how we want to put these errors as json messages alongside the rustc ones (or alongside non-ndjson message like from cargo metadata)

@epage epage added A-diagnostics Area: Error and warning messages generated by Cargo itself. S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. labels Oct 12, 2023
@est31
Copy link
Member Author

est31 commented Oct 12, 2023

Are you needing spans printed in human readable output or json

human readable output would be a great start already, specifically in the format /path/to/Cargo.toml:line:col, because that format is recognized by many tools, like Kate which opens the editor right at that spot if you pass it that string as cli arg (that'd be my Konsole + Kate workflow). In VS code, I do use rust-analyzer for some tasks but not to show the errors. Usually that I do with the built-in terminal, which turns Cargo.toml:line:col into a link too.

The format is pretty standard, it's used by many of the compilers I worked with, like gcc, clang, javac, etc. VS Code also supports linking the style python uses, which is "foo/bar.py", line 12. So IMO Cargo should switch to that format as well. #12556 has been great progress already though.

@est31
Copy link
Member Author

est31 commented Oct 12, 2023

I think, even if you assume the vs code devs were willing to add a custom format recognizer for cargo, the format currently outputted by cargo is hard to turn into a clickable link, as the filename is far away from the line and column info.

So, best to use Cargo.toml:line:col like format.

@est31
Copy link
Member Author

est31 commented Oct 12, 2023

Java:

public class Program
{
    public static void main(Stvring[] args) {
		
	}
}
./Playground/Program.java:4: error: cannot find symbol
    public static void main(Stvring[] args) {
                            ^
  symbol:   class Stvring
  location: class Program
1 error

clang:

void main(void) {
    eror
}
a.c:1:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void main(void) {
^
a.c:1:1: note: change return type to 'int'
void main(void) {
^~~~
int
a.c:2:5: error: use of undeclared identifier 'eror'
    eror
    ^

Python:

hio
Traceback (most recent call last):
  File "/home/user/src/cargo/a.py", line 1, in <module>
    hio
NameError: name 'hio' is not defined

@epage
Copy link
Contributor

epage commented Oct 12, 2023

No effort has been done to polish our existing spans: thats just what we get from toml_edit + anyhow: This is all incremental. With our diagnostic work, we plan to mirror rustc as much as possible.

@est31
Copy link
Member Author

est31 commented Oct 12, 2023

Noted. Very enthusiastic about seeing progress in that area!

@weihanglo weihanglo added S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. and removed S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. labels Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Error and warning messages generated by Cargo itself. S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

4 participants