Change:
extern crate "coherence-lib" as lib; use lib::Remote; <del> impl<T> Remote for T { } //~ ERROR type parameter `T` is not constrained </del> <ins> impl<T> Remote for T { } //~^ ERROR type parameter `T` must be used as the type parameter for some local type </ins> fn main() { }

Discussion:
As the example below demonstrates, rustc emits E0210 for a construct that does not match the description of that error. The construct might not be valid, but for a different reason (see comments).
I think this is correct behaviour. Your blanket impl can conflict with any of the other blanket impl in libcore. For example, I could write a third crate like this: And will end with two implementations, one from your crate because it implements , and another from 's . That's why the compiler rejects your blanket implementation. Also, I'd advise against using / to bypass this check, as those "features" will de removed soon-ish.
Please at least read the entirety of the reduced-case example provided (and ideally ); it includes comments that explain what happens and why it is a bug. To rehash: Unless is not a clause that constrains type parameter by local type , this error is half wrong; the second half is correct, but that's no saving grace. Additionally, the suggested workaround does absolutely nothing aside from producing warnings about that deprecated feature. You can check with . Well, yes, rustc tried to tell me that: but like many programmers I focus on the first error I get. I completely agree. But the check isn't bypassed.
RE: check not bypassed, the names you gave are correct and line 98 of needs to be modified () to suggest the correct workaround.
I apologize for not carefully reading your report! I do agree this is a diagnostics bug. At first, I thought that you were reporting a bug in the coherence checker, my bad. It's not, because is a trait not a type. I do think that the error message could have been better worded as: "type parameter does not contain any local type ...", because a type parameter like is correct. Do you think we could reword the message like that ^, or do you think it may not cover a case that's covered by the current message? Yes, I was going to mention that you need both the feature gate and the attribute next to the item, but I really think that we shouldn't advise people to use that anymore as those attributes are going away soon. How would you feel about removing the "note: workaround" message as a preparatory step for the removal of /? - I really think we shouldn't advise people to use them anymore.

(The "note: conflicting" message could have shown the actual conflicting implementations in libcore (there are several in this case) instead of showing some span in the current crate.) Please, do let me know if I missed anything else.
Nope, nothing else missed. Thanks for the quick reply! Some comments: Rust newbies like myself will find such a distinction confusing, since traits might seem type-like to those without much practice thinking about/with them. I'm not entirely sure of the meaning of "constrained by" here, but your suggested rewording makes me think of a contained struct member. Does either of or match the intended meaning?
I agree the error message is poorly worded. The intention of the word "constrained by" was that it must be "covered" or "underneath" a local type. For example, is ok, but just is not. It has nothing to do with the trait bounds at all. I'm not sure how best to phrase this, but on IRC and I considered: "type parameter must be used as the type parameter for some local type (e.g. )"
We'll also remove the / suggestions as I proposed above. I'll prepare a PR.