Change:
<ins> // run-rustfix use std::io::stdin; fn get_name() -> String { let mut your_name = String::new(); stdin() .read_line(&mut your_name) .expect("Failed to read the line for some reason"); your_name.trim().to_string() //~ ERROR E0308 } fn main() { println!("Hello, What is your name? "); let your_name = get_name(); println!("Hello, {}", your_name) } </ins>

Discussion:
When you have a function that returns a String but add to the return value to remove extraneous whitespace, you have a type error because returns a . But the suggestion is not to add or to fix the problem but to remove the trimming behavior entirely even if that is exactly what the programmer intended. When using cargo run, it additionally fails to show the line containing .trim() in the suggested change. error[E0308]: mismatched types I tried this code: I saw this happen: I expected to see this happen: No response
Not really a clippy issue, as it's a wrapper around with additional lints (and thus any bad diagnostics there will be an issue here as well). This should be changed in rustc
This suggestion should only be applied for methods that have no "side-effects" -- things like , , etc.
How do you determine whether the method has "side-effects" or not? Sorry if this is a stupid question. I'm an absolute newbie to rustc development, but would be keen to start on this issue.
No, that's a fine question. The way I would do it is probably just hard-code a set of known methods. Like... etc.
Thanks :) That's what I was thinking as well. Is it okay if I claim this issue? I presume the error originates in type checking and hence the change would go into some HIR related code. Is that correct?
As per my analysis the fix can go into the following condition in the method: We can add an extra check here for methods with side effects as shown below: where the method could be as follows: As a result of this change, will return in the situation reported in the bug and will eventually get to the  method which should automatically suggest a conversion using There's a method () which seems to be something we could use instead of , but it considers all_ method call exprs to have side effects. Therefore it may not be a good fit. With regard to tests, we could enhance to verify our case. We could also enhance . Or we could write completely new tests. What are your thoughts
While filtering on a set of hard-coded method symbols may work for , it's not a scalable solution. What we need is a general way to tell whether any given method on any given type could have side effects or not.

Since achieving something like that would be non-trivial, I don't think we have a good solution here. Perhaps a conservative, but likely unacceptable, option is to never suggest removal of methods. Then at least the suggestions in this context will always be correct although not necessarily most natural.
I personally think that would be the best solution. I don't really care that it's suggesting I fix the code, I care that it suggests I fix it by removing a method at all that the programmer likely intended to call. Though I get that a lot of people learn Rust by letting the compiler teach them. I'm in the same boat as a learner myself. Still, seems kinda silly for the compiler to be like "Oh, you want trimming? No! The type doesn't match. Remove the trim and just deal with the spaces." when "toowned()" handily fixes the problem. Maybe the compiler can tell you how to convert when the solution is as simple as "toowned()"?