summaryrefslogtreecommitdiffstats
path: root/tests/ui/methods/method-ambig-one-trait-unknown-int-type.rs
blob: 7b2fc34e1af12637ec8d6e77255d58f4119eb9dc (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// Test that we invoking `foo()` successfully resolves to the trait `Foo`
// (prompting the mismatched types error) but does not influence the choice
// of what kind of `Vec` we have, eventually leading to a type error.

trait Foo {
    fn foo(&self) -> isize;
}

impl Foo for Vec<usize> {
    fn foo(&self) -> isize {1}
}

impl Foo for Vec<isize> {
    fn foo(&self) -> isize {2}
}

// This is very hokey: we have heuristics to suppress messages about
// type annotations needed. But placing these two bits of code into
// distinct functions, in this order, causes us to print out both
// errors I'd like to see.

fn m1() {
    // we couldn't infer the type of the vector just based on calling foo()...
    let mut x = Vec::new();
    //~^ ERROR type annotations needed
    x.foo(); //~ ERROR type annotations needed
}

fn m2() {
    let mut x = Vec::new();

    // ...but we still resolved `foo()` to the trait and hence know the return type.
    let y: usize = x.foo(); //~ ERROR mismatched types
}

fn main() { }