Support registering tool attributes from command line and un-support Registry::register_attribute

[petrochenkov]

New unstable command line option -Z attr-tool=tool_name allows to use tool attributes from that tool: #[tool_name::anything].

This is supposed to

1. Move the tool attributes story further, with an eye on eventual stabilization.
2. Replace Registry::register_attribute from the legacy plugin interface which isn't going to be stabilized, but which is still used by Servo. Servo will be able to add -Z attr-tool=servo to command line and use #[servo::must_root] instead of using #[must_root] registered via plugin.

r? @nrc

[petrochenkov]

The primary alternative to a command line option is registering the tools through a crate-level attribute:

#![register_tools(servo, another_tool)]

#[servo::must_root]
#[another_tool::another_attr]
fn foo() {}

and perhaps attributes themselves as well, as a more direct replacement for Registry::register_attribute and also replacement for feature(custom_attribute):

#![register_attributes(must_root, another_attr)]

#[must_root]
#[another_attr]
fn foo() {}

I don't know what option is better and need feedback.
cc @SimonSapin @rust-lang/dev-tools

Note however, that crate-level attributes can be supplied through command line via -Z crate-attr=ATTR, so the attributes kind of subsume command line, but that option is currently unstable and intended for internal use.

[Manishearth]

I prefer the crate level attribute form, this does not make sense within a -Z flag since this forces consumers of the crate to build it in a particular manner. If anything, I find -Z to be more unstable here.

[Centril]

So if I understand this right, whether you have -Z attr-tool=servo or #![register_tools(servo)], the semantics are achieved by having an outside and separate tool read the file and then do stuff (e.g. like clippy). No procedural macro or plugin is run inside the compiler to give the attributes semantics (e.g. like in servo).

In the case of servo, as I noted in the tracking issue, I'm unsure how that brings #[must_root] closer to stable when it afaics depends on accessing the HIR (which we will never expose in a stable fashion).

[Manishearth]

It makes it easier to compile servo on stable, the must_root lint is an important compile-time check that is not necessary to produce a servo binary. Currently a blocker to making this work is that we have custom attributes peppered throughout the codebase.

[Centril]

That makes sense to me. It seems like an improvement over the status quo. However, it seems like we're possibly inviting more reliance on the internal structures of the compiler on nightly. That said, overall it seems a net benefit and I think we should do one of the two versions.

[Manishearth]

However, it seems like we're possibly inviting more reliance on the internal structures of the compiler on nightly

I'm not sure how this is the case, servo has been doing this for forever, and this doesn't really change anything.

Less nightly-ish use cases for this are basically where other tools may wish to consume this. The -Z option helps but having an attribute api is nice too.

[Centril]

I'm not sure how this is the case, servo has been doing this for forever, and this doesn't really change anything.

I was thinking it would invite more applications to do what servo does; but that's speculative and might not pan out... we'll see I guess; I support finding out. :)

[Manishearth]

I was thinking it would invite more applications to do what servo does

well yeah, but the registry api has been around forever, and if you actually want to do what servo does you need the registry api anyway, so this isn't removing any barriers or anything

[SimonSapin]

Servo will be able to add -Z attr-tool=servo to command line

I assume this is the rustc command line which Servo’s build system doesn’t drive directly, Cargo does. Increased reliance on RUSTFLAGS is problematic, because of rust-lang/cargo#5376.

[bors]

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

[shepmaster]

In a related world, I'd like to be able to write

#[derive(Example)]
#[example::attr]
struct Demo {
    #[example::attr]
    field: i32,
}

Discussing with @petrochenkov, it was suggested that something like this could be acceptable:

#[proc_macro_derive(Example, tools(example))]

[SimonSapin]

Increased reliance on RUSTFLAGS is problematic

This sounded a bit euphemistic when I read it again. To be clear, I think that requiring a rustc command-line argument is not viable for Servo. A crate-level attribute would work though.

What is the motivation for removing Registry::register_attribute while #[plugin_registrar] and Registry still exist?

[petrochenkov]

I'll close this for now and reopen later with implementation based on crate-level attributes.