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

unused_parens doesn't fire for trailing return expression #68386

Closed
varkor opened this issue Jan 20, 2020 · 4 comments · Fixed by #68479
Closed

unused_parens doesn't fire for trailing return expression #68386

varkor opened this issue Jan 20, 2020 · 4 comments · Fixed by #68479
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@varkor
Copy link
Member

varkor commented Jan 20, 2020

fn foo() -> u32 {
    let _ = (5); //~ LINT unnecessary parentheses around assigned value
    (5) // no lint
}
@varkor varkor added A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 20, 2020
@Centril Centril added C-bug Category: This is a bug. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. labels Jan 20, 2020
@Tyg13
Copy link
Contributor

Tyg13 commented Jan 22, 2020

I'd be interested in handling this.

Looking at librucst_lint/unused.rs, it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. let _ = { (5) };) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?

@varkor
Copy link
Member Author

varkor commented Jan 22, 2020

@Tyg13: what sort of ambiguity do you mean? I'd expect a single lint on (5) in your example (note that we don't yet lint about unused {}).

@Tyg13
Copy link
Contributor

Tyg13 commented Jan 22, 2020

@varkor: To use your original example,

fn foo() -> u32 {
    let a = {
        let b = 5;
        (b)
    };
    (a)
}

Both (a) and (b) are StmtKind::Expr, since they represent the implicit return at the end of a block. I was wondering if we'd care about the (b) case, and if we did, if it made sense to treat it the same as (a). If you naively add a match arm to the Stmt visitor, you get the same diagnostic for both.

@varkor
Copy link
Member Author

varkor commented Jan 22, 2020

Yes, both (a) and (b) should be linted here.

tmandry added a commit to tmandry/rust that referenced this issue Jan 24, 2020
Implement `unused_parens` for block return values

Fixes rust-lang#68386

r? @Centril
@bors bors closed this as completed in 1662888 Jan 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
3 participants