Compiler out of stack on generic base trait impl restricted to a derived trait

[mzabaluev]

Rustc runs out of stack on this program:

use std::io;
trait B {
    fn f(&self);
}

trait T : B {
}

struct A;

impl<U: T> B for U {
    fn f(&self) { io::println("Hey, I'm a T!"); }
}

impl T for A {
}

fn main() {
    let a = A;
    let br = &a as &B;
    // let tr = &a as &T;
    // let br = tr as &B;
    br.f();
}

The inheritance of trait T from B seemingly triggers the recursion: without it, the program compiles and runs fine.

P.S. The commented-out lines illustrate what I was actually trying to achieve: upcasting a trait pointer to the base trait. That didn't work for other reasons.

[bblum]

A little more minimal:

use std::io;
trait B {
    fn f(&self);
}

trait T : B { }

impl<U: T> B for U {
    fn f(&self) { io::println("Hey, I'm a T!"); }
}

impl T for int { }

fn main() {
    let _br = @0 as @B;
}

The stack overflow is a cycle between lookup_vtables, lookup_vtable, back to lookup_vtables, and each_bound_trait_and_supertraits.

[bblum]

nominating well-covered milestone

[graydon]

accepted for production-ready milestone

[pnkfelix]

just a bug, assigning P-low.

[japaric]

Both examples compile on:

rustc 0.13.0-dev (3327ecca4 2014-11-01 22:41:48 +0000)

@nikomatsakis Can we close this? Or should we add a test (if it's not covered in the test suite already)?

[alexcrichton]

Flagging as needstest (just in case)

[nikomatsakis]

Wacky. I don't think there is a test specifically covering this scenario.