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

Add E0602 #42361

Merged
merged 1 commit into from
Jun 6, 2017
Merged

Add E0602 #42361

merged 1 commit into from
Jun 6, 2017

Conversation

GuillaumeGomez
Copy link
Member

Part of #42229.

cc @Susurrus

@rust-highfive
Copy link
Collaborator

r? @eddyb

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

@Susurrus
Copy link
Contributor

Susurrus commented Jun 1, 2017

So you're making the command-line lint and the lint attribute errors separate errors then? Is this formatting in line when rustc emits errors for other command-line arguments? I wouldn't expect error numbers for command-line parsing issues, just for code-related errors (like the lint attribute error).

@eddyb
Copy link
Member

eddyb commented Jun 1, 2017

Hmm, saw @Susurrus' comment too late. @rust-lang/compiler any opinions?

EDIT: you saw nothing

@Susurrus
Copy link
Contributor

Susurrus commented Jun 1, 2017

LOL. Glad that got sorted (don't worry, I have email proof!) ✉️

@GuillaumeGomez
Copy link
Member Author

Yep, I still need to add the "code lint" error code, but it seems more logical for me in order to make better error explanation.

@GuillaumeGomez GuillaumeGomez force-pushed the error-codes branch 2 times, most recently from b56c0db to 7cc1ab4 Compare June 2, 2017 19:39
@Susurrus
Copy link
Contributor

Susurrus commented Jun 2, 2017

Sure, adding more details wouldn't be a bad thing. I think it's unnecessary, but I don't think it'd hurt for users not very comfortable at the command line (and general argument syntax).

Two questions:

  • Would it make sense to specify the name of the invalid lint?
  • Would it make sense to list all valid lints? I'm thinking about helping the user fix the issue. If they aren't positive of all the valid lints, I don't even know where I could look that info up!

@GuillaumeGomez
Copy link
Member Author

GuillaumeGomez commented Jun 2, 2017

The lint name is given iirc. And I don't think giving the full lint name list is a good idea since it's getting quite long. ;)

@shepmaster shepmaster added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 2, 2017
@arielb1
Copy link
Contributor

arielb1 commented Jun 6, 2017

Adding levenshtein-based suggestions would be nice, but I think it's a little bit to much.

@bors r+

@bors
Copy link
Contributor

bors commented Jun 6, 2017

📌 Commit 7cc1ab4 has been approved by arielb1

@arielb1 arielb1 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 Jun 6, 2017
@bors
Copy link
Contributor

bors commented Jun 6, 2017

⌛ Testing commit 7cc1ab4 with merge 76242ae...

bors added a commit that referenced this pull request Jun 6, 2017
@bors
Copy link
Contributor

bors commented Jun 6, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 76242ae to master...

@bors bors merged commit 7cc1ab4 into rust-lang:master Jun 6, 2017
@GuillaumeGomez GuillaumeGomez deleted the error-codes branch June 7, 2017 07:48
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.

7 participants