Tracking issue for on_unimplemented feature

[aturon]

The on_unimplemented feature provides the #[rustc_on_unimplemented] attribute, which allows trait definitions to add specialized notes to error messages when an implementation was expected but not found.

WARNING: This attribute, as all other rustc_ attributes, is an internal implementation detail of rustc and is not meant to become stable.

[seanmonstar]

I think this would be 'private' to rustc.

[aturon]

@seanmonstar You may well be right, although it may be a useful feature for tailoring error messages around complicated user-space trait setups as well.

[sgrif]

As someone creating a library with complicated user-space trait setups, this would be an enormously useful feature. However I did notice an issue while using it, due to blanket impls.

When adding this line, I would expect this compile fail test to contain "collections::string::String cannot be used in an expression of type yaqb::types::Serial". However, it doesn't even mention the annotated trait, since due to this blanket impl, it doesn't even mention the annotated trait (and therefore doesn't include my note). Only the one that would satisfy the constraints of that blanket impl. (This is likely another manifestation of #28894).

Also worth noting that it's impossible to test these w/ compile-fail at the moment, but that's tangential to this feature.

[SimonSapin]

Is it possible to improve the default diagnostics, without an opt-in feature?

[steveklabnik]

Triage: no real change. apparently servo uses this.

[SimonSapin]

Update: I’m moving usage of nice to have but not really required (optimizations, compiler diagnostics like this, …) unstable features in Servo behind an optional Cargo feature flag.

[Centril]

I would like to see an RFC for getting custom errors a la https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors in Rust.

[nvzqz]

What needs to be done to get this or something similar stabilized?

As some of you may know, static_assertions can have some gnarly error messages. So, I'm going to use this for nvzqz/static-assertions#24 under a nightly feature flag so then I can get much nicer errors:

error[E0277]: static assertion failed
  --> tests/messages.rs:14:1
   |
14 | assert_impl_one!(Foo: A, B, C);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   | |
   | `Foo` must implement exactly one of the given traits
   | required by `_::{{closure}}#0::AmbiguousIfMoreThanOne::some_item`
   |
   = help: the trait `_::{{closure}}#0::AmbiguousIfMoreThanOne<_>` is not implemented for `Foo`
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

It would be wonderful if everyone who uses this crate can get decent error messages.

[Centril]

This is an internal rustc_ attribute only for use by rustc. You should not rely on it. (In fact, this tracking issue should probably not exist -- @varkor should we make the the issue number to 0 and close this issue?)

[nvzqz]

Ah, I wasn't aware it was meant to be internal-only. @estebank had recommended it to me earlier today, so I figured it was fair game. What's the path to make something like this publicly usable?

[Centril]

What's the path to make something like this publicly usable?

An elaborate RFC. :) The current implementation is an ad-hoc one based solely on what the needs of rustc is and any design would need to make sure to handle errors holistically (e.g. taking into account const generics, GHCs way of doing things, etc.) and not be too tied to rustc nor rustc too tied to the attribute. At any rate, this is not a priority and I don't think the language team has the bandwidth to make it one.

[varkor]

I'm surprised this is feature gated behind anything other than rustc_private (and hence that it has a tracking issue at all). This isn't intended to ever be stabilised (in its current form) and any work towards making it user-definable would require an RFC. I think it would be appropriate to close this issue, and if people want such a feature in non-rustc crates, a new feature request issue could be opened.

[Centril]

@varkor Yeah I agree; let's move it into rustc_attrs (I think that's the right feature gate).