Change:
in Dec '22 introduced a cool new feature to suggest removing the last method call if it would alleviate a type mismatch error. This is particularly using for people wrestling with issues. in Oct '23 introduced another useful feature to suggest to users that they might consider ing an or type in order to solve a type mismatch. Also very cool, and conveniently by the same author Unfortunately, in cases where a method is called, the previous check takes precedence, and the compiler suggests removing that trailing method to get the code to compile. This isn't generally that useful as the expect suggestion, and I can't think of an example where it's a better one. If you can think of one though, please put it below for me to test! surfaced this with but it's more easily demonstrated with ints. I can see two ways to fix this: the trailing method check first, but ignore and types the checks so the option type is checked first. Note that the method check has to be high in the chain as the motive is to quickly suggest removing a call, before adding a whole load of new ones. This means the check has to be one of the first I am going to work on solving it via method 2, as it feels cleaner that the method check doesn't have to know about the and check. If anyone has strong feelings on this, please let me know! Playground No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think this suggestion for removing the method call is way too eager, as it can easily be wrong and when it's wrong it's quite confusing. Maybe it should instead say that the type was correct before the method call (which is never wrong), nudging the user towards removing the call if they know that it's not important. Instead of strongly saying that it should be removed. Alternatively, it could be special cased to known "unimportant" functions like or .
I think this brings up two issues: should the method call suggestor should do, and say. There was some discussion of this in where it was decided to keep it generic rather than special-casing, but I don't think it's done badly at the moment. Perhaps the wording could be altered? it should run I'll focus on the latter here, but if you have examples where removing the method call doesn't make sense we can aggregate them and see if there is a holistic solution?

Discussion:
// Use `||` to give these suggestions a precedence let suggested = self.suggest_missing_parentheses(err, expr) <ins> || self.suggest_missing_unwrap_expect(err, expr, expected, expr_ty) </ins> || self.suggest_remove_last_method_call(err, expr, expected) || self.suggest_associated_const(err, expr, expected) || self.suggest_deref_ref_or_into(err, expr, expected, expr_ty, expected_ty_expr)

|| self.suggest_into(err, expr, expr_ty, expected) || self.suggest_floating_point_literal(err, expr, expected) || self.suggest_null_ptr_for_literal_zero_given_to_ptr_arg(err, expr, expected) <del> || self.suggest_coercing_result_via_try_operator(err, expr, expected, expr_ty) || self.suggest_missing_unwrap_expect(err, expr, expected, expr_ty); </del> <ins> || self.suggest_coercing_result_via_try_operator(err, expr, expected, expr_ty); </ins> if !suggested { self.note_source_of_type_mismatch_constraint(

<ins> fn main() { let abs: i32 = 3i32.checked_abs(); //~^ ERROR mismatched types } </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-117669.rs:2:20 | LL |     let abs: i32 = 3i32.checked_abs(); |              ---   ^^^^^^^^^^^^^^^^^^ expected `i32`, found `Option<i32>` |              | |              expected due to this | = note: expected type `i32` found enum `Option<i32>` help: consider using `Option::expect` to unwrap the `Option<i32>` value, panicking if the value is an `Option::None` | LL |     let abs: i32 = 3i32.checked_abs().expect("REASON"); |                                      +++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>