Support registering inert attributes and attribute tools using crate-level attributes#66070
Support registering inert attributes and attribute tools using crate-level attributes#66070bors merged 5 commits intorust-lang:masterfrom
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
what's the result of attr vs tool collision?
#![register_attr(something)]
#![register_tool(something)]There was a problem hiding this comment.
They do not collide because the attribute is in macro namespace and the tool is in type namespace.
matthewjasper
left a comment
There was a problem hiding this comment.
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_attributeis not removed yet, I'll do it in a follow up PR.)Some tools (
rustfmtandclippy) 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_attributewhile also providing a replacement.register_attris a direct replacement for#, 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
# instead.Details:
register_attr/register_toolrather 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