Change:
match *name_bindings.type_def.borrow() { None => {} Some(ref ty) => { <del> let msg = format!("import `{}` conflicts with type in  this module", token::get_name(name).get()); self.session.span_err(import_span, msg.as_slice()); match ty.type_span { None => {} Some(span) => { self.session .span_note(span, "conflicting type here") </del> <ins> match ty.module_def { None => { let msg = format!("import `{}` conflicts with type in  this module", token::get_name(name).get()); self.session.span_err(import_span, msg.as_slice()); match ty.type_span { None => {} Some(span) => { self.session .span_note(span, "note conflicting type here") } } } Some(ref module_def) => { match module_def.kind.get() { ImplModuleKind => { match ty.type_span { None => { /* this can't ever happen */ } Some(span) => { let msg = format!("inherent implementations  are only allowed on types  defined in the current module"); self.session .span_err(span, msg.as_slice()); self.session .span_note(import_span, "import from other module here") } } } _ => { let msg = format!("import `{}` conflicts with existing  submodule", token::get_name(name).get()); self.session.span_err(import_span, msg.as_slice()); match ty.type_span { None => {} Some(span) => { self.session .span_note(span, "note conflicting module here") } } } } </ins> } } }

Discussion:
The code <pretrait T {} impl&lt;U: T&gt; Vec&lt;U&gt; {} fn main() { let r = Vec::fromslice(&[1u]); } </prefails with 4:36 error: unresolved name . fn main() { let r = Vec::from_slice(&[1u]); } </preRemoving the <codeimpl</codeline causes the code to compile fine. Thx Ms2ger for finding such a small example case.
I think this is related to anonymous modules appearing, resolves to a module due to the impl. If you change to this you get another interesting error:
Note that a workaround is to wrap in parens, as Then you get the correct error message about trying to on a type outside of its crate.
I've spent some time investigating this bug and I think that the cleanest thing to do is to (closed B-RFC right now, does anyone have a link to a relevant RFC?) and require to occur only in the same module as, and after, the definition of . This check would be done before creating the anonymous trait module with name . Otherwise in the case of where a definition of is not visible, is not resolved until typeck (at which point the compiler will complain if is defined outside the current crate, or not at all), but if there are resolve errors like the current bug, these will be exposed to the user first and halt compilation. The current behaviour upon encountering where has not been defined in the current module is to create a module (which shadows any other modules exposed by statements) and try to resolve any symbols into this module. This means that the current support for outside of the module is defined in is <ialready</ibroken. Consider for example will error out with "unresolved name ". I'm sure I could come up with other examples of currently broken behaviour like this.
the closing of that bug predates our RFC process, so there would not be a link to an RFC.
Interestingly, this breaks in the opposite direction if you qualify the :
My suggestion is that should be disallowed. I will submit an RFC with these changes.