Miss Dada  🏳️‍⚧️

When your refactoring causes so many errors that your "compile time" is limited by lock contention on stderr printing all the compiler errors

You just gave me a half baked idea. If `rustc` encounters >N parse errors, it should just stop and avoid trying to continue to the type checker.

In general I wish rustc would stop earlier. We have `impl<T: Expression> AsExpression<T::SqlType> for T` in Diesel. If Rust encounters a case where `AsExpression<SomeType>` isn't implemented, it assumes that the blanket impl applies, and spits out 4 more errors 1/2

Because it's now assumed that `<T as AsExpression<SomeType>>::Output` is `T`, and there are other bounds required. So now we have 4 errors about traits not being implemented when there should be one, and none of them mention `SomeType` which is the only relevant piece of info.

That sounds like a very reasonable thing to change. I wonder if there's an open issue along those lines... Also I'm wondering how it could be changed without it ever being incorrect.

I've got an RFC I'm writing to provide an attribute which can be placed on impls to tell rustc "Please do not recommend this impl". Explicit annotation is the only fix in this case I think. My desired behavior in *this* case is "Follow the impl chain to N-1 places"

This would also help in cases where you want Rust to recommend another impl, but it doesn't because there are two "possible" cases that could apply (even though one never does)