-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Support registering inert attributes and attribute tools using crate-level attributes #66070
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
|
||
#![register_attr(attr, attr)] //~ ERROR attribute `attr` was already registered | ||
#![register_tool(tool, tool)] //~ ERROR tool `tool` was already registered | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the result of attr vs tool collision?
#![register_attr(something)]
#![register_tool(something)]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They do not collide because the attribute is in macro namespace and the tool is in type namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mostly looks good. There are a few things that I would like to see tests for:
#[no_implicit_prelude]
should hide these attributes.- Using the
register*
attributes on something other than a crate should be a warning/error. - Whether registed attributes can be imported with
use
.
Ping from triage - |
They are unstable and going to be removed anyway and the removed code would complicate the next commit
Updated with the comments addressed. |
@bors r+ |
📌 Commit 83f553c has been approved by |
⌛ Testing commit 83f553c with merge b3f59a942069b71a14d6eb5991f582c054864de2... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
Wat. |
Support registering inert attributes and attribute tools using crate-level attributes And remove `#[feature(custom_attribute)]`. (`rustc_plugin::Registry::register_attribute` is not removed yet, I'll do it in a follow up PR.) ```rust #![register_attr(my_attr)] #![register_tool(my_tool)] #[my_attr] // OK #[my_tool::anything] // OK fn main() {} ``` --- Some tools (`rustfmt` and `clippy`) used in tool attributes are hardcoded in the compiler. We need some way to introduce them without hardcoding as well. This PR introduces a way to do it with a crate level attribute. The previous attempt to introduce them through command line (#57921) met some resistance. This probably needs to go through an RFC before stabilization. However, I'd prefer to land *this* PR without an RFC to able to remove `#[feature(custom_attribute)]` and `Registry::register_attribute` while also providing a replacement. --- `register_attr` is a direct replacement for `#![feature(custom_attribute)]` (#29642), except it doesn't rely on implicit fallback from unresolved attributes to custom attributes (which was always hacky and is the primary reason for the removal of `custom_attribute`) and requires registering the attribute explicitly. It's not clear whether it should go through stabilization or not. It's quite possible that all the uses should migrate to `#![register_tool]` (#66079) instead. --- Details: - The naming is `register_attr`/`register_tool` rather than some `register_attributes` (plural, no abbreviation) for consistency with already existing attributes like `cfg_attr`, or `feature`, etc. --- Previous attempt: #57921 cc #44690 Tracking issues: #66079 (`register_tool`), #66080 (`register_attr`) Closes #29642
☀️ Test successful - checks-azure |
And remove
#[feature(custom_attribute)]
.(
rustc_plugin::Registry::register_attribute
is not removed yet, I'll do it in a follow up PR.)Some tools (
rustfmt
andclippy
) used in tool attributes are hardcoded in the compiler.We need some way to introduce them without hardcoding as well.
This PR introduces a way to do it with a crate level attribute.
The previous attempt to introduce them through command line (#57921) met some resistance.
This probably needs to go through an RFC before stabilization.
However, I'd prefer to land this PR without an RFC to able to remove
#[feature(custom_attribute)]
andRegistry::register_attribute
while also providing a replacement.register_attr
is a direct replacement for#![feature(custom_attribute)]
(#29642), except it doesn't rely on implicit fallback from unresolved attributes to custom attributes (which was always hacky and is the primary reason for the removal ofcustom_attribute
) and requires registering the attribute explicitly.It's not clear whether it should go through stabilization or not.
It's quite possible that all the uses should migrate to
#![register_tool]
(#66079) instead.Details:
register_attr
/register_tool
rather than someregister_attributes
(plural, no abbreviation) for consistency with already existing attributes likecfg_attr
, orfeature
, etc.Previous attempt: #57921
cc #44690
Tracking issues: #66079 (
register_tool
), #66080 (register_attr
)Closes #29642