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 lint print_stderr #6367

Merged
merged 5 commits into from
Dec 8, 2020
Merged

Add lint print_stderr #6367

merged 5 commits into from
Dec 8, 2020

Conversation

justjosias
Copy link
Contributor

@justjosias justjosias commented Nov 22, 2020

Resolves #6348
Almost identical to print_stdout, this lint applies to the eprintln! and eprint! macros rather than println! and print!.

changelog: Add new lint [print_stderr]. [println_empty_string] and [print_with_newline] now apply to eprint!() and eprintln!() respectively.

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ebroto (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Nov 22, 2020
@bors
Copy link
Collaborator

bors commented Nov 27, 2020

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

Copy link
Member

@ebroto ebroto left a comment

Choose a reason for hiding this comment

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

Looking at the phrasing in PRINT_STDOUT documentation, it seems targetting only print and println was intended, so I think it's OK to have a separate lint for eprint and eprintln.

tests/ui/print_stderr.rs Outdated Show resolved Hide resolved
@@ -260,6 +279,10 @@ impl EarlyLintPass for Write {
);
}
}
} else if mac.path == sym!(eprintln) {
span_lint(cx, PRINT_STDERR, mac.span(), "use of `eprintln!`");
Copy link
Member

Choose a reason for hiding this comment

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

Looking at the surrounding code and the description of those lints, it seems PRINTLN_EMPTY_STRING and PRINT_WITH_NEWLINE could apply to eprintln and eprint respectively.

Would you mind doing that change in this PR? Alternatively we can open a different issue and leave it as a follow-up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The application of PRINTLN_EMPTY_STRING and PRINT_WITH_NEWLINE to eprintln and eprint would also require giving different suggestions for each case (using eprint[ln] instead of print[ln]). Should these be divided into separate lints as well?

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for adding this change!

No, I think we just need to change the suggestion depending on the case, but without adding new lints.


BTW it seems you need to rebase on top of the master branch, there are a lot of commits that are not related to this PR. Do not hesitate to ping me if you find any problem when doing that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ebroto It seems I have made a mess of the branch's history. I don't know enough git to deal with this. I've tried rebasing several times.

Copy link
Member

Choose a reason for hiding this comment

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

@justjosias it should be fixed now.

FYI I did an interactive rebase on top of the current master, which left 4 commits. 2 of them were duplicates, so I only kept the newest ones and fixed some conflicts during the rebase.

BTW do not forget to commit the changes to the stderr file; since we added some lines, the line numbers of the previous error messages has changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ebroto It appears master no longer compiles, so I can't test anything or proceed with other changes. But I fixed the stderr file.

Copy link
Member

Choose a reason for hiding this comment

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

@justjosias FYI the problem you mention has been fixed, it should work if you 1) re-run setup-toolchain.sh and 2) rebase on top of the latest master.

Copy link
Contributor Author

@justjosias justjosias Dec 4, 2020

Choose a reason for hiding this comment

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

I screwed up the history again. I'll figure out the interactive rebase to fix it.

EDIT: Fixed! Thanks for the advice. I'm now going to work on this last change.

@ebroto ebroto added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Nov 28, 2020
justjosias and others added 5 commits December 7, 2020 23:38
Resolves rust-lang#6348
Almost identical to print_stdout, this lint applies to the
`eprintln!` and `eprint!` macros rather than `println!` and
`print!`.
Get rid of the too-many-lines error.
@ebroto
Copy link
Member

ebroto commented Dec 8, 2020

FYI the CI error was related to a function having too many lines in write.rs. I've factored out some code to get rid of it.

Thanks for your contribution and don't hesitate to take another issue :)

@ebroto
Copy link
Member

ebroto commented Dec 8, 2020

@bors r+

@bors
Copy link
Collaborator

bors commented Dec 8, 2020

📌 Commit 3187cad has been approved by ebroto

bors added a commit that referenced this pull request Dec 8, 2020
Add lint print_stderr

Resolves #6348
Almost identical to print_stdout, this lint applies to the `eprintln!` and `eprint!` macros rather than `println!` and `print!`.
@bors
Copy link
Collaborator

bors commented Dec 8, 2020

⌛ Testing commit 3187cad with merge 02b0552...

@bors
Copy link
Collaborator

bors commented Dec 8, 2020

💔 Test failed - checks-action_test

@ebroto
Copy link
Member

ebroto commented Dec 8, 2020

@bors retry (missing changelog)

@bors
Copy link
Collaborator

bors commented Dec 8, 2020

⌛ Testing commit 3187cad with merge b02b0c7...

@ebroto ebroto removed the S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) label Dec 8, 2020
@bors
Copy link
Collaborator

bors commented Dec 8, 2020

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: ebroto
Pushing b02b0c7 to master...

@bors bors merged commit b02b0c7 into rust-lang:master Dec 8, 2020
@justjosias justjosias deleted the 6348-print-stderr branch December 9, 2020 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add lint print_stderr, similarly to print_stdout
4 participants