Type checker does not eagerly select predicates from where-clauses

[jonas-schievink]

The following code fails to infer the type of x, as well as the call to the inherent method as_str:

fn f<T: Into<String>>(u: T) {
    let x = u.into();
    x.as_str();
}

rustc has no problem with this code, since the .into() call will eagerly use the T: Into<String> bound from the where clause. This happens despite plenty of other Into impls existing in the wild and is an intentional Rust feature.

[flodiebold]

Interesting, I didn't realize this exists. I think this needs to be solved in Chalk, since it works even if the where clause doesn't directly match the goal (e.g. if you have a trait Into2 that's blanket-impl'd for Into). I think there actually was code for this in the old recursive solver; we removed it because we didn't come up with a test case for it.

[ANtlord]

Is there any progress on the issue? I don't want to push, I just would like to know.

[ANtlord]

@flodiebold I browsed the code, trying to understand what is executed when a type for such case is inferred.

I made the test:

#[test]
fn infer_into() {
    check_types(
        r#"
fn call(v: impl Into<u32>) {
    let n = v.into();
    n;
} //^ u32

fn test() {
    call(0u32);
}
"#,
    );
}

Of cause it fails. The thing is that it fails because the inferred type is {unknown}.

In the beginning I thought that the type inference should be fixed in
InferenceContext::infer_body. Then I took a look at InferenceContext::resolve_all. It has a
comment FIXME resolve obligations as well (use Guidance if necessary). It reminded me about the
related issue rust-lang/chalk#584 in the Chalk project. So I'm trying to
understand a couple of things:

1. Does Chalk provides everything to implement a solution for the issue?
2. Should InferenceContext::resolve_all infer the type somehow? If so, could you describe the
   idea which involved Guidance?

[flodiebold]

Your test doesn't work because neither Into nor the blanket impl for Into exist in the test, you need to either define them yourself or add //- minicore: from to the beginning of the test code. (Also, you can remove the test function.)

As to your question, no, this needs to be solved in Chalk, i.e. the issue you linked needs to be fixed. This is unrelated to InferenceContext::resolve_all.

[ANtlord]

Alright, thank you. I'll take a look at Chalk.

Speaking of the test, you're right, the test works after removing the test function. Although, adding //- minicore: from makes it failing still.

[Throne3d]

I'm also hitting into this (via #13761 / #17170) - there's a use of a borrow that isn't resolved in DataFusion, and then a destructuring that causes a later type error (because RA isn't inferring the real use of ref bindings when matching the borrow).

It looks like quite a long-standing issue, both here and in Chalk upstream (rust-lang/chalk#584). I've seen some of the discussions about the next-gen trait solver in rustc, and a few different issues suggesting RA plans to take advantage of it when it's more stabilized. Would that be expected to solve this? Also, is there an RA issue/epic for the new trait solver somewhere?

[Veykril]

Would that be expected to solve this?

Yes

Also, is there an RA issue/epic for the new trait solver somewhere?

No not yet, we are still trying to figure out how to tackle adopting the new trait solver.