Proposal: color attributes using regular syntax coloring

[georgewfraser]

Following up on #4400. Right now, Rust attributes are left as the default color. Both the TextMate grammar and the semantic coloring rules specify meta.attribute.rust, which has no effect. In the default Dark+ theme, they show up as plain white:

To me, this seems like more of an oversight than an intentional choice. Now that semantic coloring is available, rust-analyzer is "taking ownership" of syntax coloring, so it makes sense to fix this here. What do other languages do?

C# attributes are colored with normal syntax coloring, with the surrounding brackets punctuation.squarebracket.open.cs, which is the default color in Dark+:

Typescript decorators are colored with normal syntax coloring, with the @ symbol punctuation.decorator.ts, which is the default color in Dark+:

Java annotations are colored with normal syntax coloring, with the @ symbol punctuation.definition.annotation.java, which is the default color in Dark+:

Based on these precedents, I propose that we color the inner parts of Rust attributes with the normal syntax coloring rules, and the surrounding #[] as punctuation.attribute.rust, which will render as the default color in the builtin themes (as it does now).

LMK what you think @matklad

@aloucks FYI

[georgewfraser]

Proof of concept of what this might look like:

[aloucks]

I use an older version of atom one dark and currently have semantic coloring turned off until it gets sorted out a bit more.

I suspect that the changes proposed here might break existing themes that already have support for rust. I'm curious what would happen if you added the additional scopes but do not remove any of the existing ones.

[georgewfraser]

@aloucks The screenshot you show should look the same right now with semantic coloring on. #4397 should have undone the things that made semantic coloring different than TextMate coloring, except that semantic coloring is more accurate.

[Aloso]

In my opinion, the traits in #[derive] attributes should be highlighted like types, and the name of the attributes the same as normal macros:

An alternative is to highlight built-in attributes like keywords and proc-macro attributes like normal macros:

[aloucks]

IntelliJs highlighting does something similar (note that Debug is highlighted as a trait):

[georgewfraser]

@Aloso Rust attributes are strange---they're like a built-in mini-language of their own. I am still learning about them myself, but here is my understanding so far: the identifier Clone in #[derive(Clone)] isn't exactly a reference to the type std::clone::Clone---it's a constant/macro of the same name, defined by rustc. The derive attribute knows to implement the Clone trait when it sees the identifier Clone, but there's nothing in principle preventing it from doing something else. I'm not disagreeing with you, I'm just saying we should think carefully about "what do the identifiers in attributes really represent?"

[georgewfraser]

The builtin attributes appear to be defined here:

https://github.com/rust-lang/rust/blob/master/src/librustc_feature/builtin_attrs.rs

[georgewfraser]

Custom attributes can be defined as described here: https://doc.rust-lang.org/reference/procedural-macros.html

It seems the outermost layer of symbols in an attribute are always functions. The arguments to these functions are not parsed---they are passed to the functions as a stream of tokens. So they could represent anything, and there's not really any general mechanism to understand the meaning of these tokens. Having said that, hard-coded rules for builtin attributes are probably not the worst idea. For example, it would be nice if #[derive(Clone)] showed Clone as a type.

[Aloso]

Derive macros usually implement a trait of the same name. I know that this is only a convention, and might not always be true, but it's true for the built-in derives and for many crates with derives, such as serde, diesel, thiserror and many more.

Providing syntax highlighting and "Go to definition" based on this assumption is useful, with almost no downsides IMO.

You are correct about procedural macros. That is the reason why both IntelliJ and rust-analyzer don't attempt to highlight the token tree in a procedural macro, except for literals (numbers, bools, strings and chars) and keywords I believe.