Fix some suggestions for redundant_pattern_matching

[phansch]

.. and change the Applicability to MaybeIncorrect.

Fixes the problem displayed in #4344 (comment).

We now append {} to the suggestion so that the conditional has the
correct syntax again.

(If we were to remove the if instead, it would trigger the
unused_must_use warning for #[must_use] types.)

changelog: Fix some suggestions for redundant_pattern_matching

[flip1995]

I have 2 concerns here:

1. What if the if-block isn't empty? I don't see a test for that nvm there is a test and the lint doesn't trigger there.**
2. The suggestion is semantically not the same:

While this expression:

match foo {
    Ok(_) => true,
    Err(_) => false,
}

returns a bool, the suggested expression:

if foo.is_ok() {}

returns the unit type (). I'm not sure if this lint also triggers for constructs like let _ = match ...*, but if this suggestion would get applied, weird follow up type errors of rustc would be the result. (I don't think a test exists for that either)

---

* Since stray match;/if let; expressions returning something other than () are pretty rare, this lint should trigger also on those, otherwise it would be pretty useless (except the case of a match/if let (without ;) that returns from a function)

** That would be a good first issue IMO, since you just need to get the expression inside the if block and use

rust-clippy/clippy_lints/src/utils/mod.rs

Lines 534 to 536 in 7bd7d40

	/// Like `snippet_block`, but add braces if the expr is not an `ExprKind::Block`.
	/// Also takes an `Option<String>` which can be put inside the braces.
	pub fn expr_block<'a, T: LintContext>(cx: &T, expr: &Expr, option: Option<String>, default: &'a str) -> Cow<'a, str> {

to create the new block

[flip1995]

cc #4344 (comment)

Oh you already mentioned my first point. Without fixing this, we should just turn the suggestion into MaybeIncorrect

[phansch]

What if the if-block isn't empty? I don't see a test for that

Yeah, that was also brought up as a problem in #4344 and this PR doesn't address that.
One solution could be to skip the suggestion if the block contains statements.

The suggestion is semantically not the same

It seems like there are a lot of test cases missing. Maybe these suggestions should be marked as MaybeIncorrect for now? I'll have a look and see if I can fix the problem with the return type.

[flip1995]

Just edited my first comment 😉

[phansch]

@flip1995 Was this what you had in mind? I opted to stop suggesting the if ... {} conditional because, as you said, it's not the same thing as the original code. I also added more test cases but removed the // run-rustfix for now.

[flip1995]

Yeah that was somehow what I had in mind, but there are different cases, that we need to take into account before we can turn this suggestion to MachineApplicable.

New test cases look good now. One test case should be added for the auto applicability:

let x = if let Some(_) = opt { true } else { false };
takes_bool(x);
let y = if let Some(_) = opt {};
takes_unit(y);

to make sure we pass the type checker with the suggestions. I would just add them now, so we don't forget about them once someone makes these suggestions auto applicable.

[flip1995]

@bors r+

[bors]

📌 Commit 436d429 has been approved by flip1995

[bors]

⌛ Testing commit 436d429 with merge 57c67a2...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: flip1995
Pushing 57c67a2 to master...