Make "only traits defined in the current crate can be implemented for arbitrary types" less vague

[JosephTLyons]

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b04540728eae88b27ee5d19b5bc0b685

use chrono::offset::Utc;
use std::fmt::Display;

impl Display for Utc {}
fn main() {}

The current output is:

Compiling playground v0.0.1 (/playground)
error[[E0117]](https://doc.rust-lang.org/stable/error-index.html#E0117): only traits defined in the current crate can be implemented for arbitrary types
 [--> src/main.rs:4:1
](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3ba9fdd15e921f6ac1ecff15c7d0b783#)  |
4 | impl Display for Utc {}
  | ^^^^^^^^^^^^^^^^^---
  | |                |
  | |                `Utc` is not defined in the current crate
  | impl doesn't use only types from inside the current crate
  |
  = note: define and implement a trait or new type instead

For more information about this error, try `rustc --explain E0117`.
error: could not compile `playground` due to previous error

Ideally the output should look like:

Not sure... my main issue with this error is the message itself: "only traits defined in the current crate can be implemented for arbitrary types." The fact that it only mentioned "arbitrary types" leads me to believe that my only solution is to change something about the type, but I don't what that change Is supposed to be (In this case, it is using the "newtype" idiom.

The word arbitrary is vague to me - as a beginner, I don't fully know what that means. In fact, if I had to guess, I would consider both the original type, and the new type that wraps the old type, both "arbitrary," so I think the issue is around that word. I feel as if the message should not mention "arbitrary" and should rather indicate that you can only implement this trait on a type that's defined within this crate.

I do understand that the help diagnostic is nudging the user towards a newtype pattern, but my main point is that the error is pretty ambiguous to me.

[compiler-errors]

I think this can be solved super easily by taking "can be implemented for arbitrary types" and changing it based on the self type of the crate:

• ADTs - "can be implemented for types defined outside of the crate"
• builtins - "can be implemented for built-in types"
• generics - (?), but maybe something like "can have blanket implementations defined in this trait"
• other types - maybe fall back to this error message

Or something along these lines... The point is that we should specialize this message for the self type that the impl block has.

Feel free to r? me if you're working on this @TaKO8Ki, or otherwise this would be a pretty good E-easy + E-mentor issue that I would love to help someone with.

[TaKO8Ki]

@compiler-errors
I'm going to work on this!