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

Rustc explain #48337

Merged
merged 5 commits into from Feb 26, 2018
Merged

Rustc explain #48337

merged 5 commits into from Feb 26, 2018

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented Feb 18, 2018

Fixes #48041.

To make the review easier, I separated tests update to code update. Also, I used this script to generate new ui tests stderr:

from os import listdir
from os.path import isdir, isfile, join

PATH = "src/test/ui"

def do_something(path):
    files = [join(path, f) for f in listdir(path)]

    for f in files:
        if isdir(f):
            do_something(f)
            continue
        if not isfile(f) or not f.endswith(".stderr"):
            continue
        x = open(f, "r")
        content = x.read().strip()
        if "error[E" not in content:
            continue
        errors = dict()
        for y in content.splitlines():
            if y.startswith("error[E"):
                errors[y[6:11]] = True
        errors = sorted(errors.keys())
        if len(errors) < 1:
            print("weird... {}".format(f))
            continue
        if len(errors) > 1:
            content += "\n\nYou've got a few errors: {}".format(", ".join(errors))
            content += "\nIf you want more information on an error, try using \"rustc --explain {}\"".format(errors[0])
        else:
            content += "\n\nIf you want more information on this error, try using \"rustc --explain {}\"".format(errors[0])
        content += "\n"
        x = open(f, "w")
        x.write(content)

do_something(PATH)

@rust-highfive
Copy link
Collaborator

r? @michaelwoerister

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 18, 2018
\"rustc --explain {}\"",
&error_codes[0]).expect("failed to give tips...");
} else {
writeln!(self.dst,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this message show up for errors that don't show any extra information if --explain is run?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure to understand your point...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I confused this with the teach flag

@GuillaumeGomez
Copy link
Member Author

The travis failure doesn't make any sense. When I run rustc on the tests, I don't get the same output, even with the same parameters. Did I miss something (it's just like the code is run in parts and then the new error message gets printed after each of them)?

@michaelwoerister
Copy link
Member

r? @estebank

@oli-obk
Copy link
Contributor

oli-obk commented Feb 19, 2018

Did I miss something (it's just like the code is run in parts and then the new error message gets printed after each of them)?

That might be because ui tests are run with --error-format=json and the rendered field of all diagnostics are concatenated.

@GuillaumeGomez
Copy link
Member Author

Should I update how it's done then? Because right now, as I said, it has nothing in common with the actual output...

@GuillaumeGomez
Copy link
Member Author

Should be done now.

@estebank
Copy link
Contributor

Still failing :-/

Minimal difference due to JSON encoding:

[01:01:33] ---- [ui] ui/lint/use_suggestion_json.rs stdout ----
[01:01:33] 	diff of stderr:
[01:01:33] 
[01:01:33] 384	   |
[01:01:33] 385	and 8 other candidates
[01:01:33] 386	
[01:01:33] -	If you want more information on this error, try using "rustc --explain E0412"
[01:01:33] +	If you want more information on this error, try using /"rustc --explain E0412/"
[01:01:33] 388	"
[01:01:33] 389	}
[01:01:33] 390	{

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The windows/linux normalizer changes \ to /, previously the json decoder removed escape backslashes during string decoding

@@ -1629,8 +1632,8 @@ impl<'test> TestCx<'test> {
.iter()
.any(|s| s.starts_with("--error-format"))
{
rustc.args(&["--error-format", "json"]);
},
//rustc.args(&["--error-format", "json"]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leftover comment.

@GuillaumeGomez GuillaumeGomez force-pushed the rustc-explain branch 6 times, most recently from 2818fe4 to 8dbdae2 Compare February 21, 2018 15:25
@GuillaumeGomez
Copy link
Member Author

It passed tests. \o/

Copy link
Contributor

@estebank estebank left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After addressing the nitpick, r=me.

if !self.short_message && !self.error_codes.is_empty() {
let mut error_codes = self.error_codes.clone().into_iter().collect::<Vec<_>>();
error_codes.sort();
if error_codes.len() > 1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this restrict the error list to some reasonable amount? I'm ok with any amount, but I'd constrain it to at most two full 80 col lines.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it really matter? I can do it but I'm not sure if this is very useful... You're not supposed to try to have as much errors as possible when writing code haha.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be rare, but I see no reason for us not to gracefully handle that case :)

It won't ever be possible for a given project to have more than a subset of the ~600 errors the compiler has, but regardless, it is worthless to list the error codes, once the user understands how to use the flag, it makes more sense to scroll to the error that they want more information on and copy the error code from there, as the error code on it's own is meaningless.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll limit then.

@estebank
Copy link
Contributor

I still think there's value in limiting the amount of error codes listed to a reasonable amount, but it is silly to block on it.

Also, it would also be nice to have a way to disable this output, but I won't block this PR on this. We need to add a compiler config file to handle this and other cases (--teach, coloring, one line output, etc.).

@bors r+

@bors
Copy link
Contributor

bors commented Feb 21, 2018

📌 Commit 8dbdae2 has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 21, 2018
@bors
Copy link
Contributor

bors commented Feb 22, 2018

☔ The latest upstream changes (presumably #48399) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 22, 2018
@GuillaumeGomez
Copy link
Member Author

Damn, it was new tests...

@GuillaumeGomez
Copy link
Member Author

CI passed so let's r+ again (with a higher priority to avoid being outdated once again)...

@bors: r=estebank p=10

@bors
Copy link
Contributor

bors commented Feb 26, 2018

📌 Commit ce6429a has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 26, 2018
@bors
Copy link
Contributor

bors commented Feb 26, 2018

⌛ Testing commit ce6429a with merge bedbad6...

bors added a commit that referenced this pull request Feb 26, 2018
Rustc explain

Fixes #48041.

To make the review easier, I separated tests update to code update. Also, I used this script to generate new ui tests stderr:

```python
from os import listdir
from os.path import isdir, isfile, join

PATH = "src/test/ui"

def do_something(path):
    files = [join(path, f) for f in listdir(path)]

    for f in files:
        if isdir(f):
            do_something(f)
            continue
        if not isfile(f) or not f.endswith(".stderr"):
            continue
        x = open(f, "r")
        content = x.read().strip()
        if "error[E" not in content:
            continue
        errors = dict()
        for y in content.splitlines():
            if y.startswith("error[E"):
                errors[y[6:11]] = True
        errors = sorted(errors.keys())
        if len(errors) < 1:
            print("weird... {}".format(f))
            continue
        if len(errors) > 1:
            content += "\n\nYou've got a few errors: {}".format(", ".join(errors))
            content += "\nIf you want more information on an error, try using \"rustc --explain {}\"".format(errors[0])
        else:
            content += "\n\nIf you want more information on this error, try using \"rustc --explain {}\"".format(errors[0])
        content += "\n"
        x = open(f, "w")
        x.write(content)

do_something(PATH)
```
@bors
Copy link
Contributor

bors commented Feb 26, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: estebank
Pushing bedbad6 to master...

@@ -2544,6 +2545,7 @@ impl<'test> TestCx<'test> {
}
}
if !explicit {
let proc_res = self.compile_test(&["--error-format", "json"]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, let's just compile all the tests twice.
Who cares about time, certainly not Appveyor.

@zackmdavis
Copy link
Member

@GuillaumeGomez

If you want more information on an error, try using "rustc --explain {}"

I know I'm late, but I would argue that this would be better phrased as something more like:

For more information about an error, try `rustc --explain {}`

(avoids informal-sounding second person, omits needless word 'using', backticks instead of quotation marks for code).

@GuillaumeGomez
Copy link
Member Author

@zackmdavis: A bit yes. Let me update then...

@@ -115,6 +116,33 @@ struct FileWithAnnotatedLines {
multiline_depth: usize,
}

impl Drop for EmitterWriter {
fn drop(&mut self) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GuillaumeGomez (more belated commentary in light of #48550) What was the motivation for putting the this in drop()? Semantically, printing the message notifying the user about --explain does not seem like a "cleanup" action. As Niko suggested, I would kind of expect this to go with the "aborting due to previous error" message in Handler.abort_if_errors—and it looks like the Handler already knows which codes have been emitted, too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum, if this is true, it might allow to make my task for #48562.

zackmdavis added a commit to zackmdavis/rust that referenced this pull request Feb 28, 2018
This reverts commit 1dc2015, which
switched to compiling the UI tests twice rather than extracting the
humanized output from a field in the JSON output.

A conflict in this revert commit had to be fixed manually where changes
introduced in rust-lang#48449 collide with the change we're trying to revert
(from rust-lang#48337).

This is in the matter of rust-lang#48550.

Conflicts:
	src/tools/compiletest/src/runtest.rs
zackmdavis added a commit to zackmdavis/rust that referenced this pull request Feb 28, 2018
This reverts commit 9b597a1. That
commit added a message informing users about the `rustc --explain`
functionality inside of a `Drop` implementation for `EmitterWriter`. In
addition to exhibiting questionable semantics (printing a
hopefully-helpful message for the user does not seem like a "cleanup"
action), this resulted in divergent behavior between humanized output
and JSON output, because the latter actually instantiates an
`EmitterWriter` for every diagnostic.

Several conflicts in this revert commit had to be fixed manually, again
owing to code-area collision between rust-lang#48449 and rust-lang#48337.

This is in the matter of rust-lang#48550.

Conflicts:
	src/librustc_errors/emitter.rs
@zackmdavis
Copy link
Member

@GuillaumeGomez One last comment (sorry if it seems like I've been overly critical with respect to this feature; sometimes good code requires a lot of discussion, and sometimes I have a lot of things to say), but arguably the --explain usage message should come before the "aborting due to n errors" message (so that we're aborting immediately after we say that we're aborting).

@matklad
Copy link
Member

matklad commented Mar 5, 2018

TIL that you can not only rustc --explain CODE, but cargo --explain CODE as well: rust-lang/cargo#2551

The commit message on that PR implies the idea was to make rustc print just run --explain CODE and not run rustc --explain CODE or something like this (I am not sure I understand this entirely).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants