- Start Date: 2012-03-20
- RFC PR: rust-lang/rfcs#3
- Rust Issue: rust-lang/rust#14373
Summary
Rust currently has an attribute usage lint but it does not work particularly well. This RFC proposes a new implementation
Motivation
The current implementation
- There are very limited warnings for valid有効な、正しいattributes that end up in the wrong place. Something like this will be silently ignored:無視する
ItemDecorators
can now be defined定義するoutside of the compiler, and there's no way to tag them and associated attributes as valid.有効な、正しいSomething like this requires an#[allow(attribute-usage)]
:
Detailed design設計(する)
The current implementation
This RFC would change the implementationsyntax::ast::Attribute_
would be modified to add an ID field:
syntax::ast::parse::ParseSess
will generate new AttrId
s on demand. I believe that attributes will only be created during parsingParseSess
is accessible in both.
The AttrId
s will be used to create a side table of used attributes. This will most likely be a thread local to make it easily accessible during all stages of compilation by callingsyntax::attr
:
The attribute-usage
lint would run at the end of compilation and warn on all attributes whose ID does not appear
One interesting edge case is attributes like doc
that are used, but not in the normal compilation process. There could either be a separate fold pass to mark all doc
attributes as used or doc
could simply be whitelisted in the attribute-usage
lint.
Attributes in code that has been eliminated with #[cfg()]
will not be linted, but I feel that this is consistent with the way #[cfg()]
works in general
Alternatives
An alternativerustc::middle::lint
to robustly check that attributes are used where they're supposed to be. This will be fairly complex
Unresolved questions
- This implementation実装doesn't allow許可する、可能にするfor a distinction between "unused" and "unknown" attributes. The
#[phase(syntax)]
crate loading infrastructure could be extended拡張するto pull a listリスト、列挙するof attributes from crates to use in the lint pass, but I'm not sure if the extra complexity is worth it. - The side table could be threaded through all of the compilation stages that need to use it instead of being a thread local. This would probably require significantly著しくmore work than the thread local approach, however. The thread local approach should not negatively impact any future parallelization work as each thread can keep its own side table, which can be merged into one for the lint pass.