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

Suggest && and || instead of 'and' and 'or' #54181

Merged
merged 5 commits into from
Sep 16, 2018
Merged

Conversation

vi
Copy link
Contributor

@vi vi commented Sep 13, 2018

Resolves #54109.

Note: competing pull reqeust: #54179

r? @csmoe

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 13, 2018
@csmoe
Copy link
Member

csmoe commented Sep 13, 2018

cc @estebank I prefer to this PR than mine.

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.

This is great! One small piece of feedback left. r=me after dealing with it.

Thank you @csmoe too for your change.

@@ -732,6 +732,12 @@ impl<'a> Parser<'a> {
format!("expected {} here", expect)))
};
let mut err = self.fatal(&msg_exp);
if self.token.is_ident_named("and") {
err.help("Use `&&` instead of `and` for the boolean operator");
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you use the following?

err.span_suggestion_with_applicability(
    self.span,
    "use `&&` instead of `and` for the boolean operator",
    "&&".to_string(),
    Applicability::MaybeIncorrect,
);

This way the output will be presented inline and third party tools will be able to apply the suggestion in their UIs.

Same change in all four cases.

@vi
Copy link
Contributor Author

vi commented Sep 13, 2018

Appled the recommendation. Also added while tests in addition to existing if tests just in case.

Is it not a problem that output looks a bit repetitive?:

help: use `||` instead of `or` for the boolean operator: `||`

@estebank
Copy link
Contributor

There's a short span suggestion method that hides the actual suggestion and would work well for these, but it doesn't accept Applicability... I'm ok with it for now, but if you're in the mood to check it out to see if we could make it accept Applicability and modify every caller, it would be great :)

@estebank
Copy link
Contributor

@bors r+ rollup
@vi If you get to update span_suggestion_short before this PR is merged, great, otherwise it can be a follow up task.

@bors
Copy link
Contributor

bors commented Sep 14, 2018

📌 Commit 79919a7 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 Sep 14, 2018
@vi
Copy link
Contributor Author

vi commented Sep 14, 2018

As far as I understoon from the description, it is expected to change not directly related code ("modify every caller"), so another review may be needed.

Is accepting Applicability to span_suggestion_short useful for other lints, not for just this?

@estebank
Copy link
Contributor

@vi we should always be specifying Applicability. We don't as an accident of history: no one has bothered to go back and fully fix it everywhere.

@vi
Copy link
Contributor Author

vi commented Sep 14, 2018

There is already span_suggestion_short_with_applicability and it's more used than span_suggestion_short.

What Applicability should have the remaining span_suggestion_shorts?

Applied the span_suggestion_short_with_applicability for now.

@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Sep 14, 2018

📌 Commit bc63a4a has been approved by estebank

@vi
Copy link
Contributor Author

vi commented Sep 15, 2018

Also tried replacing all span_suggestion[_short] with span_suggestion[_short]_with_applicability of Applicability::Unspecified.

Shall I just push it or submit another pull reqeust? Shall abandoned functions be deprecated?

@estebank
Copy link
Contributor

@vi that change would be great as a stand alone PR. Remember to fix indentation when needed and changing the stderr files.

@vi
Copy link
Contributor Author

vi commented Sep 15, 2018

fix indentation

cargo fmt -- --check shows a lot of unrelated changes and I'm not sure what is correct indentation.

changing the stderr files

Assuming the change touches tests?

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Sep 16, 2018
Suggest && and || instead of 'and' and 'or'

Resolves rust-lang#54109.

Note: competing pull reqeust: rust-lang#54179

r? @csmoe
bors added a commit that referenced this pull request Sep 16, 2018
Rollup of 5 pull requests

Successful merges:

 - #53941 (rustdoc: Sort implementors)
 - #54181 (Suggest && and || instead of 'and' and 'or')
 - #54209 (Partially revert 674a5db "Fix undesirable fallout [from macro modularization]")
 - #54213 (De-overlap the lifetimes of `flow_inits` and `flow_{un,ever_}inits`.)
 - #54244 (Add a small search box to seach Rust's standary library)

Failed merges:

r? @ghost
@bors bors merged commit bc63a4a into rust-lang:master Sep 16, 2018
@estebank
Copy link
Contributor

fix indentation

cargo fmt -- --check shows a lot of unrelated changes and I'm not sure what is correct indentation.

I believe I was referring to making sure that when a line is above 100 cols, you change it as you did in this PR:

	        e.span_suggestion_short_with_applicability(
                    self.span,
                    "use `&&` instead of `and` for the boolean operator",
                    "&&".to_string(),
                    Applicability::MaybeIncorrect,
                );

Assuming the change touches tests?

Correct :)

@berkus
Copy link
Contributor

berkus commented Sep 19, 2018

errrr... why?

how is && or || more readable and understandable than and / or? Apart from everything else I'd rather not see &&/|| in the code at all. Even for C++ I use and/or as human-readable equivalents of the pseudographic garbage.

@vi
Copy link
Contributor Author

vi commented Sep 19, 2018

@berkus I think Rust is just based on C in that aspect. C has &&, so Rust has &&. Haskell also have a convention that operators are special characters and functions are letters. This pull request does not set or enforce &&/||, it just specifically hints them for users who used and/or by mistake.

If in future some edition of Rust decides to implement both and and && (like in Perl), or just the former like in Python, this suggestion will be modified accordingly.

@berkus
Copy link
Contributor

berkus commented Sep 21, 2018

I agree that linter is not to blame here, but where and how can I suggest the more readable and/or alternatives for inclusion/use in the language?

@estebank
Copy link
Contributor

@berkus submit an RFCS.

@vi
Copy link
Contributor Author

vi commented Sep 21, 2018

I also like Perl-style && and and mix. But it's too Perl.

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.

6 participants