Unhelpful "Sized not implemented for str" (or slices) after method lookup error.

[eddyb]

fn main() {
    let x = ().foo();
    <i32 as std::str::FromStr>::from_str(&x);
}

<anon>:2:16: 2:19 error: no method named `foo` found for type `()` in the current scope
<anon>:2:9: 2:10 error: the trait `core::marker::Sized` is not implemented for the type `str` [E0277]

Because of the method error, x doesn't get a type (not even TyError, AFAICT), and then it gets inferred to str from another call in the function, which results in the unsized variable error.

[eddyb]

cc @nrc

[eddyb]

I'd expect a simple fix for this would be to actually set TyError as x's type, so it can't be inferred to anything else, although that could make other errors less informative.

[lnicola]

I just spent a lot of time looking at a Foo does not have a constant size known at compile-time error. The Use of undeclared type or module Foo errors were hidden by a couple of screens of "doc comment not used by rustdoc" warnings.

Because Foo was unknown, the compiler assumed it implemented no traits at all, leading to misleading errors below and user confusion: "why isn't it Sized when this other similar type similar is?", "how can I find out if a type is Sized" and so on.

I don't know if TyError works like that, but in this case it might be better to assume that the type implements any trait it's required to.

[eddyb]

That doesn't really work out, since the issue here is that inference gets a free pass instead of inferring TyError which would at least signal anything. The fix seems simple, I really don't know why I haven't tried it yet

[lnicola]

I'm not saying that the type should be inferred to something else from the code below (like you said it was happening in the issue description) -- that seems bad. But on the other hand the compiler should probably not report an error every place the type or variable is used.

[eddyb]

I just reread, and:

Because Foo was unknown, the compiler assumed it implemented no traits at all

That's not relevant here - the problem is inference flows up into the variable, which is correct in other cases but in this case it infers the slice type which is unsized. The Sized error is a mere side-effect.

[estebank]

The underlying cause is that we have two maps for HirId→Ty, a general one and one for locals. When type checking we write to the general one but the one for locals is only written to once, during initialization, and the we read from it. If we kept it up to date or read from the general map, the knock-down error wouldn't appear.