Split register_tool into register_attribute_tool and register_lint_tool by nbdd0121 · Pull Request #158038 · rust-lang/rust

nbdd0121 · 2026-06-17T16:09:01Z

Tracking issue: #66079

This implements the attribute parsing part of RFC 3808. The resolution part is yet to be implemented.

It is also removed.

This splits the functionality to two parts per RFC. The `#![register_tool]` attribute registers the tool in both ways. Semantics remain unchanged and will be adjusted in later commit.

Under the RFC, it's not an error to register tool multiple times, but it is an error to register a predefined tool, or register "rustc" tool.

rustbot · 2026-06-17T16:09:05Z

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

rustbot · 2026-06-17T16:09:08Z

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 20 candidates

rust-log-analyzer · 2026-06-17T17:18:39Z

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

...............................F.................. (50/144)
.................................................. (100/144)
............................................       (144/144)

======== tests/rustdoc-gui/go-to-collapsed-elem.goml ========

[ERROR] line 40
    at `tests/rustdoc-gui/go-to-collapsed-elem.goml` line 21: Error: Node is detached from document: for command `click: "//*[@id='search']//a[@href='../test_docs/struct.Foo.html#method.must_use']"`
    at <file:///checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/test_docs/struct.Foo.html?search=t_use>


<= doc-ui tests done: 143 succeeded, 1 failed, 0 filtered out

Error: ()

nbdd0121 · 2026-06-17T17:25:11Z

Error seems to be flaky rustdoc test: #157747

mejrs · 2026-06-17T17:30:23Z

r? me

(Or Jonathan I suppose)

mejrs · 2026-06-17T17:36:24Z

Can you expand on the "resolution yet to be implemented" thing? I was under the impression there would be no resolution and it'd all be, essentially, stringly typed.

nbdd0121 · 2026-06-17T17:55:17Z

Can you expand on the "resolution yet to be implemented" thing? I was under the impression there would be no resolution and it'd all be, essentially, stringly typed.

In https://github.com/rust-lang/rfcs/blob/master/text/3808-register-tool.md it mentioned that ambiguity between tool attribute and other resolution should be an error, and also that tool attribute is not affected by no_implicit_prelude. These are technically breaking changes so I'd want to split it to another PR so it gets a crater run.

mejrs

Typically when there are multiple attributes which are semantically related, we "merge" them into a single attribute. See https://doc.rust-lang.org/nightly/nightly-rustc/rustc_attr_parsing/index.html#how-this-crate-works

This implementation doesn't; you'd be dealing with RegisteredTool { kind: sym::register_lint_tool, ..}, RegisteredTool { kind: sym::register_tool, ..} and RegisteredTool { kind: sym::register_attribute_tool, ..}. That's three attributes, effectively. I've pointed at some places that need changes for that.

Also, my understanding from the rfc is that resolution and ambiguity errors are only for attribute_tool? i.e. #[my_tool::thing]? and not #[allow(my_tool::lint)]?

View changes since this review

mejrs · 2026-06-17T20:51:08Z

+    RegisterTool {
+        kind: Symbol,
+        tools: ThinVec<Ident>,
+    },


So I would expect this to look like...

Suggested change

RegisterTool {

kind: Symbol,

tools: ThinVec<Ident>,

},

RegisterTool {

lint_tools: ThinVec<Ident>,

attribute_tools: ThinVec<Ident>,

},

and if you use register_tool the name would be put into both of those.

^ Agreed on this, it must never be possible to have two of the same variant in an attribute list in the HIR

Attribute tools and lint tools are handled very differently in the compiler, and there're very few cases you'd want to know both, so I want to keep the queries distinct.

Perhaps I should split the HIR attr to two variants two? But I do want to avoid duplicated code because the parsing of the two attributes are very similar.

You could just make a function that parsers the attributes, and call that from the two distinct attribute parsers

This doesn't work as this will run into Attribute ["register_tool"] has multiple accepters

mejrs · 2026-06-17T20:58:11Z

+pub(crate) struct RegisterAttributeTool;
+pub(crate) struct RegisterLintTool;
+pub(crate) struct RegisterTool;

-impl CombineAttributeParser for RegisterToolParser {
-    const PATH: &[Symbol] = &[sym::register_tool];
+pub(crate) trait RegisterToolKind: 'static {
+    const SYMBOL: Symbol;
+}
+
+impl RegisterToolKind for RegisterAttributeTool {
+    const SYMBOL: Symbol = sym::register_attribute_tool;
+}
+
+impl RegisterToolKind for RegisterLintTool {
+    const SYMBOL: Symbol = sym::register_lint_tool;
+}
+
+impl RegisterToolKind for RegisterTool {
+    const SYMBOL: Symbol = sym::register_tool;
+}
+
+pub(crate) struct RegisterToolParser<Kind>(Kind);
+
+impl<K: RegisterToolKind> CombineAttributeParser for RegisterToolParser<K> {
+    const PATH: &[Symbol] = &[K::SYMBOL];
    type Item = Ident;
-    const CONVERT: ConvertFn<Self::Item> = |tools, _span| AttributeKind::RegisterTool(tools);
+    const CONVERT: ConvertFn<Self::Item> =
+        |tools, _span| AttributeKind::RegisterTool { kind: K::SYMBOL, tools };


And this would need to implement AttributeParser directly. For example see the stability parser:

rust/compiler/rustc_attr_parsing/src/attributes/stability.rs

Line 64 in 693b3e4

impl AttributeParser for StabilityParser {

which combines #[stable], #[unstable] and #[rustc_allowed_through_unstable_modules] into a single semantic attribute.

mejrs · 2026-06-17T21:01:00Z


-    if let Some(Attribute::Parsed(AttributeKind::RegisterTool(tools))) =
+    if let Some(Attribute::Parsed(AttributeKind::RegisterTool { kind: _, tools })) =
+        AttributeParser::parse_limited(sess, pre_configured_attrs, &[sym])


Unfortunately you can only use parse_limited for one attribute at a time; you can't parse multiple attributes at a time. Feel free to make a function that allows multiple attributes though, if you need it.

petrochenkov · 2026-06-18T11:50:21Z

-    /// Tool modules introduced with `#![register_tool]`.
-    ToolPrelude,
+    /// Tool modules introduced with `#![register_tool]` or `#![register_attribute_tool]`.
+    ToolAttributePrelude,


Suggested change

ToolAttributePrelude,

AttributeToolPrelude,

It's a prelude for tools, not for attributes.

I'd probably just keep the ToolPrelude naming here, because lints do no go through name resolution, but may be better to be more explicit for readers less aware of the context.

View changes since the review

petrochenkov · 2026-06-18T12:02:51Z

+#![register_attribute_tool(qux)]
+#![register_attribute_tool(qux)]


@jyn514 is there a specific reason for

#![register_attribute_tool(qux)] #![register_attribute_tool(qux)]

to be allowed?
I don't see the explanation in the RFC.
Duplicate definitions are typically prohibited in name resolution.

View changes since the review

petrochenkov · 2026-06-18T12:05:28Z

Naming nit: "attribute" is long, so it's usually abbreviated to "attr" in the compiler, so all the AttributeToolPrelude/registered_attribute_tools internal stuff could be shortened to AttrToolPrelude/registered_attr_tools/etc.

petrochenkov · 2026-06-18T12:06:13Z

The resolution part is yet to be implemented.

Please, assign me when the resolution part is submitted.

rust-bors · 2026-06-19T14:01:38Z

☔ The latest upstream changes (presumably #158124) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

nbdd0121 added 4 commits June 17, 2026 16:59

Stop mentioning register_attr feature from custom_attribute

1dab4b1

It is also removed.

Split register_tool into register_attribute_tool and register_lint_tool

6c2f5a8

This splits the functionality to two parts per RFC. The `#![register_tool]` attribute registers the tool in both ways. Semantics remain unchanged and will be adjusted in later commit.

Remove duplicate tool error and add predefined error

096f6a2

Under the RFC, it's not an error to register tool multiple times, but it is an error to register a predefined tool, or register "rustc" tool.

Add test for register_{attribute,lint}_tool with cfg

7d917c1

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 17, 2026

rustbot assigned wesleywiser Jun 17, 2026

rustbot assigned mejrs and unassigned wesleywiser Jun 17, 2026

petrochenkov self-assigned this Jun 17, 2026

mejrs requested changes Jun 17, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 17, 2026

petrochenkov reviewed Jun 18, 2026

View reviewed changes

petrochenkov removed their assignment Jun 18, 2026

		#![register_attribute_tool(qux)]
		#![register_attribute_tool(qux)]

Uh oh!

Conversation

nbdd0121 commented Jun 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 17, 2026

Uh oh!

rustbot commented Jun 17, 2026

Uh oh!

rust-log-analyzer commented Jun 17, 2026

Uh oh!

nbdd0121 commented Jun 17, 2026

Uh oh!

mejrs commented Jun 17, 2026

Uh oh!

mejrs commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nbdd0121 commented Jun 17, 2026

Uh oh!

mejrs left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mejrs Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

nbdd0121 Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

nbdd0121 Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

mejrs Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

mejrs Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov Jun 18, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov Jun 18, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Jun 18, 2026

Uh oh!

petrochenkov commented Jun 18, 2026

Uh oh!

rust-bors Bot commented Jun 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

nbdd0121 commented Jun 17, 2026 •

edited by rustbot

Loading

mejrs commented Jun 17, 2026 •

edited

Loading

mejrs left a comment •

edited

Loading

mejrs Jun 17, 2026 •

edited

Loading

petrochenkov Jun 18, 2026 •

edited by rustbot

Loading

petrochenkov Jun 18, 2026 •

edited by rustbot

Loading