Introduce a #[rustc::*] tool attribute namespace and provide a stable #[rustc::on_unimplemented] attribute

[weiznich]

Proposal

Rustc cares a lot about producing good error messages so that users know why their code failed to compile. It is sometimes possible to give specific hints based on the involved code. For cases were trait bounds where not satisfied the compiler supports adding hints to the trait definition and specific implementation about how potential error messages should be displayed. This is currently implemented via the #[rustc_on_unimplemented] compiler internal attribute.

This MCP proposes exposing this functionality in such a way that users with a stable toolchain can use a similar attribute to hint error messages for specific trait related error cases. This has as real world impact of existing code bases as demonstrated in the following PR's:

• Diesel
• Bevy
• Axum

As part of my rust foundation community grant I've collected additional examples of error messages that might be improved in a similar way here.

As part of this MCP I propose the following changes:

• Based on RFC-2103 we introduce a #[rustc::…] tool attribute namespace. This namespace is explicitly reserved in the mentioned RFC.
• Rename the existing internal #[rustc_on_unimplemented] attribute to #[rustc::on_unimplemented]
• Provide said attribute as part of the stable compiler interface with the following semantics:
  • It hint's the compiler about certain error messages, but rustc does not guarantee that anything happens
  • It accepts any set of parameters, but the compiler may choose to only interpret some/none of them and warn against all others that are unused. This should not cause compilation to fail. Although it might be useful to implement this as lint so that crates can deny it locally for development.
  • Add documentation about how to use this attribute in it's current implementation. This should include guidance about how well written error messages should look like to follow the general style of other rustc error messages.

By using a tool attribute we make #[rustc::on_unimplemented] explicitly not part of the language but rather than a compiler feature. Alternative implementations already need to handle similar attributes for rustfmt and clippy, so there is likely already existing infrastructure for such attributes.
By using #[rustc::on_unimplemented] as hint we allow the rust compiler to evolve its error reporting and by accepting any set of parameters we allow the rust compiler to remove now unneeded parameters easily.

RFC-2397 seems to be related as well. We might want to use a tool attribute there as well or improve the existing #[rustc::on_unimplemented] functionality to cover this use case as well.

Previous discussion on IRLO

Mentors or Reviewers

Esteban Küber: @estebank

If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[apiraino]

As discussed on Zulip, closing in favor of a full-fledged RFC