suggest ? when method is missing on Result<T, _> but found on T

[compiler-errors]

The wording needs help, I think.

Fixes#95729

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[mejrs]

Thanks! ❤️

The wording needs help, I think.

This is an mistake I see newbies make all the time (e.g. in the rust discord) and often this is their first time they encounter Result. IMO it would be better if this error (also) said something along the lines of "this is a result, you need to handle it".

[estebank]

This is checking that the return type is something that ? can coerce to, right? If the return type isn't that, maybe we can 1) suggest changing the return type and 2) use .unwrap(). If we do 2), then we should also support this for Option. We can also build some scaffolding to suggest using if let, which could work for any ADTs...

[compiler-errors]

Hmmm... I'm not sure if I want to encourage people to .unwrap, though I don't know if we have precedent for that in other suggestions. Or at least, maybe I'll suggest expect.

[estebank]

If we can do the more involved if let suggestion, that'd be fine by me to skip the unwrap.

[compiler-errors]

If we can do the more involved if let suggestion

Are you suggesting we transform something like:

result.call();

into

ifletOk(value) = result {
value.call();}

Because if so, I'd probably want to reserve that for a follow-up PR. I need to think of heuristics for when it's meaningful to do so, because I wouldn't want to suggest it for any nested expression, but only ones that are reasonably statement-like on their own. Like not suggesting it when the bad method call is here:

let closure = || call_something(result_needs_unwrap.call(),other_expression());// ^^^^^^^^^^^^^^^^^^^^^^^^^^

[estebank]

Yes, and point taken. As follow up work what we could so is check if the current ty is an enum, and prove each variant that has a single value for the type and emit a note saying "the variant Result::Ok(Ty) has method foo" (but still special case for Result and Option).

[compiler-errors]

Yeah, I've been thinking of this a bit more, and I would also like to generalize some sort of message to more enums somehow in a follow-up PR.

Let me special-case it for Result and Option in this PR, along with suggesting .expect (and/or changing the return type of the function) when we don't return Result.

[nagisa]

r? @estebank

[compiler-errors]

@rustbot author

[bors]

☔ The latest upstream changes (presumably #96428) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

should this just fixup to .unwrap? I kinda prefer .expect just because it feels like better practice out of the two.

[estebank]

I know what you mean, expect is better style, but unwrap ends up looking cleaner... I can be convinced either way.

[compiler-errors]

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #96459) made this pull request unmergeable. Please resolve the merge conflicts.

[estebank]

Need to continue reviewing, but so far this is a work of art ❤️

[estebank]

LGTM, but left some nitpicks.

[estebank]

Let's add a check for async fn as well. I'm intrigued if they work without further changes.

[bors]

☔ The latest upstream changes (presumably #97239) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

@rustbot ready

[estebank]

This would entail looking for methods equivalent to .expect based on heuristics, right?

[compiler-errors]

Maybe, or something like suggesting if let Pattern(destructure) = value { .. }. Not sure how useful that is, though.

[estebank]

I think it'd be worth it

[estebank]

@bors r+

[bors]

📌 Commit 2a61f0c has been approved by estebank