Suppress follow-up errors in type checking

[flodiebold]

In this situation:

fn foo() {
    let x = something_broken;
    x.max(1);
}

we currently emit a mismatched-arg-count diagnostic because we resolve the max call to Iterator::max. We should avoid emitting diagnostics in such a situation, because x was already of an unknown type.

Doing this isn't easy though and requires some refactoring, so this issue is unactionable for now.

[lnicola]

Just curious, how are we resolving max on an unknown type? Is chalk doing that?

[bjorn3]

No, that is something rust-analyzer does. Chalk only handles trait solving, not method resolution.

[lnicola]

So does this happen for inherent methods too, or only for trait methods? It seems like something is saying "we don't know the type of x, but max must be Iterator::max because it's in scope".

[flodiebold]

During method resolution, we ask Chalk 'does this unknown type implement that trait?' and Chalk says 'maybe', so we select the method.

One easy step that would fix most of the issues already would be to check in the argument count diagnostic whether the receiver is unknown.

[lnicola]

Would it make sense to take "maybe" as "no"? I'm not sure how often that happens, but in the long run I'd assume that's what the compiler will do.

[flodiebold]

No, at that point we need to accept 'maybe'; the compiler does the same. When the method is selected, an obligation is registered to make sure it later becomes a 'yes'.

[flodiebold]

One easy step that would fix most of the issues already would be to check in the argument count diagnostic whether the receiver is unknown.

Did that: #7125

[grinapo]

I'm not sure this is the same but I get mismatched-arg-count for this (possibly stupid) fragment:

       let r = rows.next(); // rusqlite::Rows
       match r { 
            Some(r) => match r {
               Ok(r) => {
                    println!( "{:20} {:<10}  {:>20}→{:>20} {:15} {:15}⇒{:15} {:15} {:20} (c{})",  
                        r.get::<usize,String>(5), r.get::<usize,String>(1), …

while it compiles fine.

[flodiebold]

I assume you get the error on the get calls? What type does RA show for r?

[grinapo]

The bold parts are complained at:
r.get::<usize,String>(5), r.get::<usize,String>(1),

r is a Row according to the popup in vscode.

[flodiebold]

That's weird. Can you make a new issue, ideally with a small reproduction?

[Veykril]

Is this still relevant? The initial snippet no longer triggers a diagnostic for me

[flodiebold]

I think the general topic is still relevant.

[Ten0]

Since the recent update I'm getting:

no field `xxx` on type `&{unknown}`

errors. Shouldn't we silence such errors when the type involves unknown?

[lnicola]

Can we close this after #16583 and the previous changes?

[Veykril]

I'd say yes, there are probaly more occasions we should look at but those will pop up when we find them