Type bounds are ignored in trait and impl function definitions

[fhahn]

It seems that rustc does not check if the type paramater satisfy the declared type bounds in trait and impl function definitions, but only for bare functions. Rustc fails on the following code with the following, rather confusing, error message: type &mut std::collections::hash::set::HashSet<[u8]> does not implement any method in scope named insert

But I think that rustc should fail at an earlier stage, because [u8] does not implement core::marker::Sized.

use std::collections::HashSet;

struct Bar;

impl Bar {
    fn test(bar: &mut HashSet<[u8]>) {
        let x: [u8; 3] = [1, 2, 3];
        bar.insert(x);
    }
}

trait Foo {
    fn test(&self, _: &mut HashSet<[u8]>);
}

The following code is a more general example and does not depend on any library.

trait Cons {
    fn myFn(&self);
}

struct Foo<T: Cons> {
    field: T
}

trait Kaboom {
    fn foo(&self, x: Foo<u8>) {}
   // this does NOT fail, but Foo<u8> is no valid type
}

struct KaboomStruct;

impl KaboomStruct {
    fn bar(&self, x: Foo<u8>) {}
   // this does NOT fail, but Foo<u8> is no valid type
}

fn foo(x: Foo<u8>) {}
// this fails, beacuse u8 does not implement Cons

[fhahn]

In this commit, I managed to reuse the existing infrastructure to check the bounds of impl function items. I do not really have an in depth understanding of the well formedness checks, but if this approach is reasonable I am pretty sure it is possible to avoid most of the duplicated code.

But I could not get this approach to work for trait items, because it relies on blank_fn_ctxt.

[pnkfelix]

AFAICT, there is no unsoundness exposed by these examples, since any attempt to create instances of the types one needs to pass (to invoke the functions that are unchecked here) will fail ... right?

I agree there is a bug here; I just want to double-check the above, in terms of how to triage it.

[fhahn]

Yes I think it should not be unsound, as it should be impossible to create structs that do not satisfy their type constraint. Also calling a function that was defined in a bound will raise an error. The only problem with this is that rustc does not check the well-formedness of impl and trait function items and this leads to pretty confusing error messages.

[pnkfelix]

cc @nikomatsakis

[nikomatsakis]

I've noticed this sort of thing before. I can look into it. Probably worth trying to do before 1.0.

[nikomatsakis]

triage: P-high (1.0)

[apasel422]

This is related to #19182.

[apasel422]

A similar issue with default type parameters that compiles successfully:

trait Bar {}
struct Foo<T = usize>(T) where T: Bar;

Foo<usize> cannot be constructed, but it doesn't make sense to allow T to be defaulted to usize. It seems that this could be a backwards compatibility issue, if we ever wanted to forbid this nonsensical declaration in the future. The same goes for default type parameters in other kinds of items.