#![register_{attribute,lint}_tool]#3808
Conversation
Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com>
- mention that `rustdoc -w json` will include the attributes - fix semver-checks spelling - apparently adding `inline` can be a breaking change 🙄
|
going to go ahead and ping all the authors of extern tools that i know, in no particular order:
|
|
I would happily use this in
Both of those are very blunt instruments, and thoroughly unsatisfying as an answer to our users. This RFC addresses those problems directly. I'm excited to see it. |
How would you be able to leverage this? irrc rustdoc gives you immediate attributes but not enough other attributes to resolve lint levels. |
this is not a rustdoc problem. this is a language level problem. semver-checks would have the same problem if it were using |
|
oh, i misunderstood, you were asking how semver-checks would use this if it were implemented. i would expect semver-checks to reimplement the precedence rules for lints, or to document that it doesn't support module-level lint controls. it doesn't have CLI flags, which means |
- make cargo registration the main user interface - specify that `no_implicit_prelude` does not affect tools
- all ambiguity is forbidden, not just tool<->local ambiguity. as a result, there is no change to precedence order. - no special-casing for attribute macros; tools are visible in any context in the type namespace - the suggested way to add a new built-in tool is "wait for an edition"
celinval
left a comment
There was a problem hiding this comment.
It's awesome to see this moving forward. Thanks!
For Kani, it's better to include @zhassan-aws / @carolynzech.
|
|
||
| Like today, attributes and lints in a tool namespace are always considered used by the compiler. The compiler does not verify the contents of any tool attribute, except to verify that all attributes are syntactically valid [tool attributes]. | ||
|
|
||
| Registering a predefined tool (`clippy`, `miri`, etc.) using `#![register_*_tool(...)]` is an error. |
There was a problem hiding this comment.
Where will this list be maintained?
Also, today you can't add any attribute that starts with rustc. Will that still be the case?
There was a problem hiding this comment.
You can see a full list at https://doc.rust-lang.org/nightly/reference/attributes.html#tool-attributes. That list is currently not as complete as the list in this RFC; I will make sure to update it.
Also, today you can't add any attribute that starts with rustc. Will that still be the case?
I assume you mean namespaced tool attributes like rustc::xxx, not "bare" attributes like rustc_const_stable. I expect those to still be banned. The story there is kind of a mess because there are rustc:: lints and they are feature-gated, but differently than the rest of the compiler's feature gates ... but I don't think we need to resolve that in this RFC. I will mention that the rustc:: tool namespace is currently and will continue to be reserved.
There was a problem hiding this comment.
Yes, I mean namespaced tool attributes that starts with rustc, for example, rustc_foo::bar. Today you can register a tool rustc_foo, but the compiler will reject the attribute #[rustc_foo::bar] (playground link):
#![feature(register_tool)]
#![register_tool(rustc_foo)]
#[rustc_foo::bar]
fn main() {
println!("🦀")
}There was a problem hiding this comment.
oh, i see. this is actually not coming from the register_tool code, this is the same code that rejects #[rustc_baz].
i think it is fairly reasonable to keep this reserved, but i can make sure it's rejected earlier in register_tool so that people aren't confused.
There was a problem hiding this comment.
but i can make sure it's rejected earlier in register_tool so that people aren't confused.
I don't think it makes sense to prevent this, there are many other ways to make an unusable attribute that are not rejected, like mod rustc_something { pub use my_attribute; } or use my_attribute as rustc_something;, but we do not prohibit modules or imports containing rustc preventively.
There was a problem hiding this comment.
As long as we are consistent. Either it works without any hacks or it fails early on.
|
I (static analysis software developer) would totally use this for any annotation that is not a contract. Thanks for your work! |
(Yup). FWIW, the main downside with this proposal is that it requires some extra work on the user's POV. Here's the current Crubit workflow:
(We used to use tool attributes, before @cramertj created this new setup.) Now, with the proposal, AIUI, to have a similar workflow using tool attributes, the user must both depend on the attribute macro crate, as well as independently register the tool attribute which the proc macro will generate. This is unfortunate -- the user needs to do two things, and needs to know the name of the tool attribute even if they never spell it. I like the proc macro wrapper, because it can force compile-time errors even if you happen to not be running the tool at the moment. The metadata Crubit consumes is not necessarily simple and so does need some validation. My preference as far as user experiences go are that a proc macro can generate inert attributes without them being registered by the crate that uses the proc macro, or else that there's a globally-available tool attribute, similar to I'm hoping this helps. FWIW, we have a working process, and I think this proposal is certainly compatible with many paths forward that lead to what I want, and definitely doc-comments are a bit... egh. Thanks for all your work here, and thanks for soliciting more feedback! I really appreciate it. |
Register "klint" as a tool so that rustc understands that `#[klint::attr]` is a tool attribute and `klint::lint` is a tool lint. This makes use of the `register_tool` feature which has been implemented as a nightly feature for long time and has an active RFC. The feature does not change any functionality, simply make it possible for Rust to recognize extra tools in addition to the built-in hardcoded ones (clippy & rustdoc). Link: rust-lang/rfcs#3808 Signed-off-by: Gary Guo <gary@garyguo.net>
|
Document regarding contract rfc is no longer accessible |
|
@tmvkrpxl0 I'm not sure what's wrong with the website, but the document can be viewed here: https://github.com/rust-lang/rust-project-goals/blob/main/src/2024h2/Contracts-and-invariants.md |
|
@rfcbot reviewed Thanks @jyn514 for pushing this forward and for the care that clearly went into this RFC. Admittedly, this RFC leaves me a bit dissatisfied. In other places, we've been pushing toward more pervasive path-based resolution and away from the exceptions to that. This goes a bit the other way. But having now looked this over carefully, I see why. I don't have any better ideas. And this use case is important. So let's do it. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. |
This updates section headers to use Markdown 2nd level headings. As part of rust-lang#3883 we switched the template to not use level-1 headings
|
The lang team has accepted this RFC, and we've now merged it. Thanks to @jyn514 for pushing forward this important work, and thanks to all those who reviewed the RFC and provided useful feedback. For further updates, please follow the tracking issue: |
View all comments
Rendered
Co-authored by @BD103.
Thank you to everyone who gave feedback on early versions of this RFC.