Type Checker getting confused with constraints + ICE

[CryZe]

I've written the same code in 2 different crates. One compiles perfectly fine, the other doesn't. Apparently the constraints on the function merge(!!) with the constraints of the other function and the type checker is getting really confused and errors out. If you look at the code, the constrained type Q does not come in contact with convex_hull::create in any way, yet it influences it. Removing Q from the function lets convex_hull::create compile just fine.

Also the compiler is complaining about a type called convex_hull::Vector3, which doesn't exist, it's called Vec3. Vec3 is actually a reexport of Vector3 as Vec3, which then got reexported again (and I think again). So maybe somewhere the type checker got confused by that and now thinks it needs to look for a type called Vector3. Not sure if that's related to the problem at all though, just seems like maybe another small bug.

[eddyb]

Looks like this is #30472.

[CryZe]

It's not, it also gets confused if I remove the HRTB and add the lifetime
to the function's generics.

It's definitely related to the Deref and / or lifetimes though. Just requiring IntoIterator makes it work.

Also, convex_hull::create has the same signature, with the same constraints, so this isn't about the constraints themselves, as they work perfectly fine in other places. It's about this particular combination that confuses the compiler.

Am Freitag, 27. Mai 2016 schrieb Eduard-Mihai Burtescu :

Looks like this is #30472 #30472
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#33904 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABYmbpGQXrpK79RHDJjVGNICwx67Nw5qks5qFwnngaJpZM4IoabF
.

[eddyb]

@CryZe With associated types under HRTB, the compiler cannot tell that two identical-looking bounds are the same, or that they imply each-other. This has been a problem for as long as HRTB has existed.

[CryZe]

As you can see here, I just removed all HRTB and it still doesn't compile.

It still expects Q even though there's no Q on convex_hull::create, just P.

At least it correctly named convex_hull::Vec3 as na::Vector3 instead of convex_hull::Vector3 this time :D (actually nvm, na is also a renamed reexport, so it's still kind of wrong).

[CryZe]

This is just getting weirder and weirder:

[eddyb]

The Rust compiler never uses type parameter names from callees in error messages in callers.
It's type-checking concave_hull::create, which has a Q parameter, so that's what it will say.

[eddyb]

@CryZe Could you reduce to one file that we can reasonably work with? (The ICE is likely #33852 AFAICT)
I don't see any reason having two crates is actually relevant here, other than potential confusion.

[CryZe]

The ICE seems to be caused by the Vec not being able to type infer its type from the constraint. Explicitly giving it a type makes it work. Nvm, it's even more weird.

[CryZe]

Here's the reduced code: https://is.gd/DHxfbu

ICE happens on Beta and Nightly. Type Checker problem happens on all.

pub fn problem_creator<'a, P>(_: &'a P) 
    where &'a P: IntoIterator<Item = &'a f64> 
{}

pub fn ok() {
    let points = Vec::new();
    problem_creator(&points)
}

pub fn ok2() {
    let points: Vec<f64> = Vec::new();
    problem_creator(&points)
}

pub fn ice<'a, Q>(_: &'a Q)
    where &'a Q: IntoIterator<Item = &'a f64>
{
    let points = Vec::new();
    problem_creator(&points)
}

pub fn broken_typechecking<'a, Q>(_: &'a Q)
    where &'a Q: IntoIterator<Item = &'a f64>
{
    let points: Vec<f64> = Vec::new();
    problem_creator(&points)
}

fn main() {}

[eddyb]

Ahh, I see what happens: problem_creator expects &$0: IntoIterator and the bound is actually satisfied by &Q: IntoIterator, which results in $0 == Q even though points has type Vec<f64>.
However, obligations like &$0: IntoIterator get resolved before arguments are checked, so that's how this arises.
I suspect #33852 fixes the ICE, but I'm not sure. cc @nikomatsakis @arielb1

[eddyb]

@CryZe As a workaround, problem_creator::<Vec<_>>(&points) seems to work for me, could you try that (explicitly specifying type parameters) in your own project?

[CryZe]

Yeah, seems to work. Thanks for your help :)

[arielb1]

@eddyb

That's the standard "inference guessing" issue (#30767).

[eddyb]

@arielb1 Is the ICE fixed?

[arielb1]

@eddyb

it looks like the Vec one, but that didn't reach nightly yet.