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

Warn about unnecessary parentheses upon assignment #12366

Conversation

milibopp
Copy link
Contributor

Fixes #12350.

Parentheses around assignment statements such as

let mut a = (0);
a = (1);
a += (2);

are not necessary and therefore an unnecessary_parens warning is raised when
statements like this occur.

NOTE: In let declarations this does not work as intended. Is it possible that they do not count as assignment expressions (ExprAssign)? (edit: this is fixed by now)

Furthermore, there are some cases that I fixed in the rest of the code, where parentheses could potentially enhance readability. Compare these lines:

a = b == c;
a = (b == c);

Thus, after having worked on this I'm not entirely sure, whether we should go through with this patch or not. Probably a matter of debate. ;)

@@ -337,8 +337,7 @@ fn get_metadata_section_imp(os: Os, filename: &Path) -> Option<MetadataBlob> {
let minsz = cmp::min(vlen, csz);
let mut version_ok = false;
vec::raw::buf_as_slice(cvbuf, minsz, |buf0| {
Copy link
Member

Choose a reason for hiding this comment

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

These lines could be

let version_ok = vec::raw::buf_as_slice(cvbuf, minsz,
                                        |buf0| buf0 == encoder::metadata_encoding_version);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

@alexcrichton
Copy link
Member

When dealing with let foo = (bar) you'll have to look for StmtDecl which is a statement instead of an expression.

@milibopp
Copy link
Contributor Author

Thanks for the advice. Let's see if the tests reveal more unnecessary parentheses that way.

@milibopp
Copy link
Contributor Author

Done. There were actually a lot more cases of declarations violating the intended lint. The set of changes throughout the standard library should serve as examples of code to judge whether this PR should be accepted or not.

@alexcrichton
Copy link
Member

Alas, good old cfg'd out blocks of code hitting the new warning.

@pnkfelix
Copy link
Member

@alexcrichton is it worth discussing whether x = y == z; is actually preferable to x = (y == z);? Or do we just land this and see if people complain?

@milibopp
Copy link
Contributor Author

I only saw one error in bors' logs and fixed it. Is this all or did bors just not go beyond that first one? Especially since some of the test runs were apparently aborted.

@pnkfelix
Copy link
Member

@aepsil0n bors aborts the other runs when one fails, so yeah, you do not necessarily know if the fixes you added will actually fix other platforms.

@alexcrichton
Copy link
Member

@pnkfelix I figured it was rare enough that we could see how people feel after this lands.

@milibopp
Copy link
Contributor Author

I do not understand why compile-fail/lint-unnecessary-parens.rs actually fails here. It's supposed to do that, so why does the test suite consider this an error?

@huonw
Copy link
Member

huonw commented Feb 20, 2014

There's an extra warning being generated:

warning: variable `a` is assigned to, but never used, #[warn(unused_variable)] on by default'

(One of the rather-too-long-lines toward the end of the test log in the buildbot failure link starts with "error: unexpected compiler error or warning" and that contains the above message (this is the test runner saying that the compiler gave extra output it wasn't expecting).)

You could name the variable _a (leading underscore silences that warning) or add an #[allow(unused_variable)]; attribute to the test.

@milibopp
Copy link
Contributor Author

I see, thanks for the explanation. Will fix asap.

EDIT: should work now

@alexcrichton
Copy link
Member

(needs a rebase)

Closes rust-lang#12366.

Parentheses around assignment statements such as

    let mut a = (0);
    a = (1);
    a += (2);

are not necessary and therefore an unnecessary_parens warning is raised when
statements like this occur.

The warning mechanism was refactored along the way to allow for code reuse
between the routines for checking expressions and statements.

Code had to be adopted throughout the compiler and standard libraries to comply
with this modification of the lint.
@milibopp
Copy link
Contributor Author

Rebased and resolved a couple of conflicts.

bors added a commit that referenced this pull request Feb 22, 2014
…d_assigned_values, r=alexcrichton

Fixes #12350.

Parentheses around assignment statements such as

```rust
let mut a = (0);
a = (1);
a += (2);
```

are not necessary and therefore an unnecessary_parens warning is raised when
statements like this occur.

NOTE: In `let` declarations this does not work as intended. Is it possible that they do not count as assignment expressions (`ExprAssign`)? (edit: this is fixed by now)

Furthermore, there are some cases that I fixed in the rest of the code, where parentheses could potentially enhance readability. Compare these lines:

```rust
a = b == c;
a = (b == c);
```

Thus, after having worked on this I'm not entirely sure, whether we should go through with this patch or not. Probably a matter of debate. ;)
@bors bors closed this Feb 22, 2014
@milibopp milibopp deleted the feature/unnecessary_parens_around_assigned_values branch February 23, 2014 09:47
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 25, 2022
…, r=lnicola

Revert "internal: Publish universal VSIX to make VS happy"

Reverts rust-lang/rust-analyzer#12349
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 4, 2024
Remove `unwrap` from `match_trait_method`

Unused_IO_amount relies on `match_trait_method` in order to match trait methods that exist in Tokio traits as the corresponding symbols don't exist.

With this commit we remove the unwrap that caused rust-lang#12366.
Note: author (`@m-rph)` and `@GuillaumeGomez` couldn't replicate rust-lang#12366.

changelog:none

r? `@blyxyas`
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.

Unnecessary parens could warn on let foo = (bar);
5 participants