the type of this value must be known in this context

[compressed]

This was working for me a few days ago, but seems to fail now due to an ICE.

Example

#![feature(associated_types)]

#[deriving(Show, Copy)]
pub enum AnimalError {
    ErrAnimal,
}

trait Animal {
    type Sized? T;
    fn new(t: &Self::T) -> Self;
}

#[deriving(Show)]
struct Dog {
    name: String
}

impl Animal for Dog {
    type T = str;
    fn new(s: &str) -> Dog {
        Dog {name : s.to_string()}
    }
}

impl Animal for Result<Dog, AnimalError> {
    type T = int;
    fn new(i: &int) -> Result<Dog, AnimalError> {
        Ok(Dog {name : format!("{}",i).to_string()})
    }
}

fn main() {
    let d = Animal::new(&123).unwrap();
}

Trace

❯❯❯ rustc --version                            ⏎
rustc 0.13.0-nightly (10d99a973 2014-12-31 21:01:42 +0000)
❯❯❯ RUST_BACKTRACE=1 rustc trait_ice.rs        ⏎
trait_ice.rs:33:13: 33:39 error: the type of this value must be known in this context
trait_ice.rs:33     let d = Animal::new(&123).unwrap();
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~
trait_ice.rs:33:13: 33:24 error: internal compiler error: ambiguity from something other than a trait: Binder(ProjectionPredicate(<_ as TraitRef(_, Animal)>::T, _))
trait_ice.rs:33     let d = Animal::new(&123).unwrap();
                            ^~~~~~~~~~~
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libsyntax/diagnostic.rs:123

stack backtrace:
   1:        0x10b200515 - sys::backtrace::write::ha2004d7552d95a80Xut
   2:        0x10b2252e3 - failure::on_fail::h158e51da7e7e7b42EDz
   3:        0x10b18ae3a - rt::unwind::begin_unwind_inner::hdbcf34d1c8e0e91f8kz
   4:        0x1090aab47 - rt::unwind::begin_unwind::h1979539420006791692
   5:        0x1090aaadc - diagnostic::SpanHandler::span_bug::h44cd9decebbf80a0fPF
   6:        0x108898e20 - middle::traits::error_reporting::report_fulfillment_error::hdc9cd6490335fdb3NXO
   7:        0x108775002 - middle::traits::error_reporting::report_fulfillment_errors::h2c6ce23b95568e6eiXO
   8:        0x1080a6222 - check::vtable::select_all_fcx_obligations_or_error::h545fc2f3572e6d4fPnb
   9:        0x10816534a - check::check_bare_fn::h37e30ed3fcd2cd69zAj
  10:        0x10815c84f - check::check_item::h07af1ef81fbd8851BTj
  11:        0x1082edb90 - check_crate::unboxed_closure.39841
  12:        0x1082e93f3 - check_crate::h8a17065eed9533a1gNx
  13:        0x107b0aaf2 - driver::phase_3_run_analysis_passes::hfbea6efbabd5412eqva
  14:        0x107af788c - driver::compile_input::hb95b6e80e64e2faewba
  15:        0x107c291d3 - thunk::F.Invoke<A, R>::invoke::h12817112036656791171
  16:        0x107c26330 - rt::unwind::try::try_fn::h17368462539297626619
  17:        0x10b28d309 - rust_try_inner
  18:        0x10b28d2f6 - rust_try
  19:        0x107c26a76 - thunk::F.Invoke<A, R>::invoke::h213923948037817051
  20:        0x10b211884 - sys::thread::thread_start::h3c81cbd736c98217Gkw
  21:     0x7fff903fb2fc - _pthread_body
  22:     0x7fff903fb279 - _pthread_body

[nikomatsakis]

The fix for the ICE is in #20412, but the code will still not compile. This is because the Self type is not constrained in any way in the expression creating the animal, but was instead relying on the fact that there was just one impl. This kind of inference is slightly less aggressive now.

[nikomatsakis]

Oh, I see, it was inferring based on the argument type, which is an associated type. Well, that also will not work -- if the argument is an associated type, we don't take it into account when selecting traits. We used to. That was issue #18437

[compressed]

Ah thanks @nikomatsakis for looking at this.

Is there any way to get behavior similar to above now?

[compressed]

This seems to work without any error:

fn main() {
    let d: Result<Dog, AnimalError> = Animal::new(&123);
    let d1 = d.unwrap();
    println!("{}",d1);
}

[remram44]

Indeed, it works fine... this should be closed!