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

False positive in block_in_if_condition_stmt: block generated by macro #3482

Closed
dtolnay opened this issue Dec 2, 2018 · 1 comment
Closed
Labels
C-bug Category: Clippy is not doing the correct thing good-first-issue These issues are a good way to get started with Clippy I-false-positive Issue: The lint was triggered on code it shouldn't have

Comments

@dtolnay
Copy link
Member

dtolnay commented Dec 2, 2018

fn main() {
    let option = Some(true);

    if option.unwrap_or_else(|| unimplemented!()) {
        unimplemented!()
    } else {
        unimplemented!()
    }
}
warning: in an 'if' condition, avoid complex blocks or closures with blocks; instead, move the block or closure higher and bind it with a 'let'
 --> src/main.rs:4:33
  |
4 |     if option.unwrap_or_else(|| unimplemented!()) {
  |                                 ^^^^^^^^^^^^^^^^
  |
  = note: #[warn(clippy::block_in_if_condition_stmt)] on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#block_in_if_condition_stmt
  = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

It doesn't look like there is a complex block or closure with block in the if-condition, although maybe the unimplemented!() macro expands to a block. The same lint does not trigger on || unimplemented() in the same position, so I believe it should also not trigger for || unimplemented!().

I believe this is a different false positive from #1141.


clippy 0.0.212 (b2601be 2018-11-27)

@oli-obk oli-obk added C-bug Category: Clippy is not doing the correct thing good-first-issue These issues are a good way to get started with Clippy labels Dec 3, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Dec 3, 2018

just needs a macro check

@oli-obk oli-obk closed this as completed in a8a0b23 Dec 6, 2018
oli-obk added a commit that referenced this issue Dec 6, 2018
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue May 5, 2020
Fixes clippy toolstate.

Changes:
````
Remove -preview suffix from README
rustup clippy build with latest rustc (breakage due to rust-lang/rust@08f8fae )
Forgot to remove some debugging code ...
Improved code noted by clippy.
Fix bug in `implicit_return`. Bug was already covered by test, but test was not checked for.
fix rust-lang#3482 and add ui test for it
Don't change current working directory of cargo tests
Use cargo's "PROFILE" envvar and set CLIPPY_DOGFOOD
Use dogfood_runner for deterministic test ordering
Remove unnecessary documentation
Fix dogfood tests.
Added additional reasoning to `Why is this bad?`. Added comment to explain usage of MIR.
Renamed to `implicit_return`. Covered all other kinds besides `ExprKind::Lit`. Added check for replacing `break` with `return`.
Appeasing the Test Gods. Seems I'm not smart enough to run the tests locally before committing.
Renamed `forced_return` to `missing_returns`. Better clarification in the docs. Ran `update_lints`.
Added `FORCED_RETURN` lint.
````
@rustbot rustbot added the I-false-positive Issue: The lint was triggered on code it shouldn't have label Sep 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing good-first-issue These issues are a good way to get started with Clippy I-false-positive Issue: The lint was triggered on code it shouldn't have
Projects
None yet
Development

No branches or pull requests

3 participants