Tracking issue: RFC 2103 - attributes for tools

[nrc]

Support scoped attributes for white-listed tools, e.g., #[rustfmt::skip]

RFC
discussion thread

• implement for attributes (mentoring instructions here)
• implement for lints (Implementation of tool lints. #52018; see Tracking issue: RFC 2103 - attributes for tools #44690 (comment))
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Current status: stabilised for attributes, some work still to do on lints.

[repnop]

As mentioned on the Gitter chat, I'm willing to take a try at this! Should just need pointed in the right direction :)

[nikomatsakis]

@petrochenkov I suspect you'd be the best one to write up some mentoring instructions here. Any chance you can put some thought into it?

[repnop]

I'll definitely be getting myself familiar with the parser and AST in the mean time, so no big rush!

[nikomatsakis]

OK, since @petrochenkov has been busy, let me take a shot at some notes. Perhaps he can correct me if he thinks things could be done a better way.

To start, the structure that represents attributes in the AST is called Attribute. From what I can tell, the parser already parses attributes and permits them to contain general paths.

Basically, the model is this: within the AST, an attribute is just a token tree. However, sometimes, the compiler tries to parse and impose structure on this tree by parsing it as something like #[derive(Foo)]. This parsed form is represented as a MetaItem struct.

This parsing that converts an Attribute into a MetaItem is when you wind up with an error due to something like #[foo::bar(...)]. In particular, such a path is flagged as an error by the helper parse_meta. One part of this RFC then is just to tweak this check to permit some cases of non-identifier paths.

However, we must also decide how to expand MetaItem -- right now, it's name field has type Name -- i.e., a single name -- but we now want to represent compound names like a::b. The hackiest thing to do would be to intern the combined string as a big string. A less hacky thing would probably be to change Name into Vec<Name> -- or perhaps an enum that chooses between a single name and multiple names. I'm not sure which is the best way forward there.

[nikomatsakis]

@rep-nop hey, I'm just checking in -- are you still hacking on this? How's it going?

[repnop]

@nikomatsakis sorry, school has been keeping me fairly busy lately but things look like they're starting to lighten up for now! I spent ~2ish hours about 2 weeks ago on it and was getting somewhere I think, but I'm going to be hopefully trying a new approach that I hope will work better within the week (if not today even!)

[nikomatsakis]

@rep-nop great =) Let me know if I can be of any assistance.