New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for `on_unimplemented` feature #29628

Open
aturon opened this Issue Nov 5, 2015 · 7 comments

Comments

Projects
None yet
7 participants
@aturon
Member

aturon commented Nov 5, 2015

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.

@seanmonstar

This comment has been minimized.

Contributor

seanmonstar commented Nov 9, 2015

I think this would be 'private' to rustc.

@aturon

This comment has been minimized.

Member

aturon commented Nov 9, 2015

@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

This comment has been minimized.

Contributor

sgrif commented Nov 11, 2015

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

This comment has been minimized.

Contributor

SimonSapin commented Dec 18, 2015

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

@steveklabnik

This comment has been minimized.

Member

steveklabnik commented May 19, 2017

Triage: no real change. apparently servo uses this.

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Oct 13, 2017

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

This comment has been minimized.

Contributor

Centril commented Sep 15, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment