false errors on methods from non implemented traits

[arturoc]

Sometimes function calls on objects that have a method implementation are taken as coming from a trait that is not really implemented by that struct and marked as an error do to incorrect arguments.

For example a struct that has an impl like:

impl Gui {
    fn fold() {
    }
}

will show errors on gui.fold() reporting it as Iterator::fold as missing two arguments. Iterator is not implemented for that struct.

The problem arises, I think, when the type for the variable can't be resolved.

[jonas-schievink]

Can you give a self-contained example?

[flodiebold]

Probably anything like

let gui = some_unresolved_function_that_should_return_gui();
gui.fold();

It actually doesn't really matter where the gui comes from -- currently we just put in a new type variable to try to give more useful completions in a case like that, but deriving diagnostics from that becomes a problem. We need to get better at tracking which types are "poisoned" and suppressing diagnostics in those cases. That's kind of what the Unknown type is for, but as mentioned we replace it by a type variable. So we need to either stop doing that, or keep track of the origin of the type variable (which we want to do anyway) and use that to suppress diagnostics.

(We also sometimes use Ty::Unknown as a placeholder where a type variable should later be inserted, so this needs some untangling.)

[arturoc]

Yes, I'll try to give a self contained example but it's pretty much what @flodiebold points out. This wasn't happening until a couple of weeks ago but now it happens in a lot of places which lowers usability of rust-analizer a lot

[flodiebold]

It wasn't happening until recently because we didn't have this diagnostic (based on RA's type inference) yet. @jonas-schievink maybe we should make the diagnostic opt-in until we can make it more robust? Or at least opt-out?

[jonas-schievink]

Yeah, I'm thinking of adding an additional "Type-based diagnostics" toggle for this