Don't ICE when uncallable functions occur due to unsatisfiable where clauses

[erickt]

UPDATED DESCRIPTION:

We now allow the original problem, but some corner cases are still unhandled. See comments below.

ORIGINAL DESCRIPTION:

Where clauses right now require predicates to contain type parameters, as in:

trait Foo {
    fn foo(&self);
}

struct Bar<T> {
    x: T,
}

impl<T> Foo for Bar<T> where T: Foo {
    fn foo(&self) {
        self.x.foo()
    }
}

But we cannot add constraints on non-generic types:

struct Baz { x: i32 }

impl Foo for Baz where i32: Foo {
    fn foo(&self) {
        self.x.foo()
    }
}

Will error out with:

test.rs:15:1: 19:2 error: cannot bound type `i32`, where clause bounds may only be attached to types involving type parameters
test.rs:15 impl Foo for Baz where i32: Foo {
test.rs:16     fn foo(&self) {
test.rs:17         self.x.foo()
test.rs:18     }
test.rs:19 }

In hand written code this usually won't come up, but this would be really helpful for a code generator like macro_rules! or #[derive], especially when dealing with associated types. Currently the only way to know if a type is generic or not is to manually walk it and see if any of the type paths start with the same name as a type parameter. If so, add that type to the predicate list. Instead, it would be much simpler if we could just add all the types listed in a field or enum to the predicate list and let the type checker report an error if one of those types doesn't implement the trait.

cc @nikomatsakis, @jroesch

[nikomatsakis]

So I think this is a good reason to just permit where clauses like this. Ideally we'll report errors at the callee, though it's easiest to report errors at the caller.

[nikomatsakis]

@erickt you seem to have disappeared from IRC, but the point about privacy is a good one -- I feel like the privacy rules are being too strict here.

[nikomatsakis]

I'm not so sure about the privacy thing any more. After some conversation with @aturon we felt like the current rules might be best.

[Gankro]

Should this be closed as wontfix/intended, then?

[jroesch]

I lost track of this, did anyone remove the check that ensures bound types include a type parameter? I remember we had talked about shuffling around some error reporting as well, but its been too many days since I've thought about this.

[huonw]

@Gankro I think the privacy rules are somewhat orthogonal to allowing non-generic where clauses (although the motivating use case is definitely undermined by the current privacy rules).

[steveklabnik]

Triage: this now works. Full reproduction:

trait Foo {
    fn foo(&self);
}

impl Foo for i32 {
    fn foo(&self) { println!("success {}", self); }
}

struct Baz { x: i32 }

impl Foo for Baz where i32: Foo {
    fn foo(&self) {
        self.x.foo()
    }
}

fn main() {
    let b = Baz { x: 5 };
    b.foo();
}

[nikomatsakis]

Huh. When did that happen? I know there have been some pending PRs about this, but there were some thorny issues, and I didn't realize that we'd made any actual changes here. @arielb1, do you know?

[arielb1]

What? I didn't implement this?

[mitaa]

I think this is the relevant commit: dbf994b

[nikomatsakis]

Yeah I was wondering if this was somehow fallout from that change. That's a bit unexpected though.

[nikomatsakis]

So we do need a solution that addresses this example raised by @arielb1 👍

#[no_mangle]
pub fn bogus<'a>(x: &'a mut ()) where &'a mut (): Clone {
    <&'a mut ()>::clone(&x);
}

The key point in this example is that this where clause could never hold -- but because it's only parametric over a lifetime, we will try to trans it, and find that there is no existing impl. This could either fail in typeck -- but we'd have to search for impls using an erased parameter -- or else fail in trans -- where the absence of an impl could cause us to emit a trap or something like that, on the premise that the fn should not in fact be callable.

Basically in trans we can just check if we know statically that the fn could never be called and generate a trap or what have you. Or just don't translate it. Or something. This seems similar to the logic that we use to screen things out of vtables.

[nikomatsakis]

triage: P-medium

[nrc]

triage: P-medium

[nikomatsakis]

triage: P-medium

[brson]

P-low?

[steveklabnik]

Triage: @nikomatsakis 's sample compiles, but if you try to use it, can never work. Aka, this is still an issue, as far as I can tell.