Struct with an error magically becomes a function, causing misleading diagnostics (arc is a function, perhaps you wish to call it)

[kornelski]

fn main() {
    let arc = std::sync::Arc::new(oops);
    arc.clone();
}

It correctly diagnoses that oops is undeclared. It should stop after this error, and not display any further errors related to the incomplete arc object.

But it continues and displays a second error, which doesn't make any sense and has a nonsense suggestion:

error[E0599]: no method named `clone` found for struct `Arc<_>` in the current scope
 --> src/main.rs:5:9
  |
5 |     arc.clone();
  |         ^^^^^ method not found in `Arc<_>`
  |
  = note: `arc` is a function, perhaps you wish to call it

Meta

rustc --version --verbose:

rustc 1.52.0-nightly (8e54a2113 2021-02-13)
binary: rustc
commit-hash: 8e54a21139ae96a2aca3129100b057662e2799b9
commit-date: 2021-02-13
host: x86_64-apple-darwin
release: 1.52.0-nightly
LLVM version: 11.0.1

[osa1]

I briefly looked into this issue. I guess there could be many ways of fixing this, but something strange I discovered as I debug this is this function

https://github.com/rust-lang/rust/blob/8535ec3ccea2530c70927966450e066c7a92a3fc/compiler/rustc_typeck/src/check/method/suggest.rs#L32-L69

returns true for Arc<_>, which is represented as an ADT (TyKind::ADT). So the last line (predicate_may_hold(FnOnce)) returns true. I think this doesn't make sense, as Arc doesn't implement FnOnce. Fixing this would fix this issue.

There could be other ways of fixing this as well, however the function that generates this suggestion, report_method_errors, is 805 lines long, and have no documentation other than a few inline comments.

[notriddle]

I think this doesn't make sense, as Arc doesn't implement FnOnce

If it autoderefs to something that impl Fn, then the suggestion would actually make sense. And it’s a free type variable, so it might.

I think the mistake here is using predicate_may_hold, which returns true on ambiguous results, instead of predicate_must_hold_modulo_regions, which should return false.

[osa1]

Hm, you're right. For example, this works:

use std::sync::Arc;

fn f() {
    println!("f called");
}

fn main() {
    let f = Arc::new(f);
    f();
}

I agree that it shouldn't return true when in case of an ambiguity/unknown type.

[osa1]

Confirmed that using predicate_must_hold_modulo_regions "fixes" the incorrect suggestion.

Of course this doesn't fix the nonsensical error message, just removes the invalid suggestion.

[Kestrer]

I encountered another variant of what seems to be this bad diagnostic recently, this time caused by a missing type parameter in an impl block:

struct Struct<T>(T);
impl Struct<T>
where
    T: Copy,
{
    fn method(v: Vec<u8>) { v.len(); }
}

Produces (as well as a helpful diagnostic) this diagnostic:

error[E0282]: type annotations needed
--> src/lib.rs:6:31
  |
6 |     fn method(v: Vec<u8>) { v.len(); }
  |                               ^^^ cannot infer type
  |
  = note: type must be known at this point

error[E0599]: no method named `len` found for struct `Vec<u8>` in the current scope
--> src/lib.rs:6:31
  |
6 |     fn method(v: Vec<u8>) { v.len(); }
  |                               ^^^ private field, not a method
  |
  = note: `v` is a function, perhaps you wish to call it

Playground here. I'm not sure whether it's worth filing a new issue for this, but if it is appropriate please do.