methods in trait impls should override default methods

[nrc]

E.g.,

trait T {
    fn foo(&self) {}
}

impl<'a> T+'a {
    fn foo(&self) {}
}

Should be OK. (It currently gives "duplicate definition of value foo").

Follow up to #17750

[nrc]

To explain what needs doing and why I didn't just do it as part of #17750:

Resolve works by creating modules for namespaces. In the above example there will a top level module, then should create separate modules for the trait T and the impl T. However, resolve uses an ast::Name to lookup these modules. So, when it gets to the impl, it tries to find a module for T and finds the trait, where the method foo is already defined.

The fix, I suppose, is to use something other than just an ast::Name as the key for looking up namespace modules (perhaps a NodeId or a key object combining a kind of item and a Name). But this is a relatively major change to resolve, so I think it is worth separating out from the implementation work for #17750.

[nrc]

When we do this, we must check (and add a test for) coherence still working with trait impls. E.g.,

trait T {
    fn foo(&self);
}

impl<'a> T+'a {
    fn foo(&self) {}
}

impl T for int {
    fn foo(&self) {}
}

fn main() {
    let x: &T = &42i;
    x.foo(); //~ERROR
}

Here, x.foo should cause a coherence error since both impls are in scope.

This is not possible right now because there will a name clash between the required method in the trait and the provided method in the trait impl.

[nikomatsakis]

Interesting. Per the UFCS RFC, T::foo should resolve to the trait, and <T>::foo should resolve to the inherent fn

[frewsxcv]

This compiles now. Someone apply the 'needs-test' label

[frewsxcv]

Fixed by #40296