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 tool attributes from command line and un-support `Registry::register_attribute` #57921

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@petrochenkov
Copy link
Contributor

petrochenkov commented Jan 26, 2019

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

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Jan 26, 2019

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

This comment has been minimized.

Copy link
Member

Manishearth commented Jan 26, 2019

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

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 26, 2019

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

This comment has been minimized.

Copy link
Member

Manishearth commented Jan 26, 2019

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

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 26, 2019

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.

@petrochenkov petrochenkov changed the title Support registering tool attributes from command line an un-support `Registry::register_attribute` Support registering tool attributes from command line and un-support `Registry::register_attribute` Jan 26, 2019

@Manishearth

This comment has been minimized.

Copy link
Member

Manishearth commented Jan 26, 2019

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

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 26, 2019

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

This comment has been minimized.

Copy link
Member

Manishearth commented Jan 27, 2019

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

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Jan 28, 2019

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

This comment has been minimized.

Copy link
Contributor

bors commented Feb 7, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment