This extension is excellent and exactly what I have been looking for. I was disappointed to find that the easier-to-use and somewhat more feature-rich rust-analyzer extension is not supported. It seems to override this extension and they cannot work in tandem. My solution was to copy your "rust.tmLanguage.json" to the downloaded rust-analyzer folder and change the name to "rust.tmGrammar.json" after deleting their file by the same name. Because rust-analyzer uses its own syntax tree it did not seem to notice the difference. I now have the best of both worlds: good code analysis and perfect syntax highlighting.

Since it was so easy, it might be worth submitting this grammar to the actual repository for rust-analyzer since it is going to replace RLS as the official IDE language server. Presumably that extension will then be the official extension for Rust in VS Code. Otherwise it may help attract more users to just support the rust-analyzer extension with this one.

// This example will show where I am noticing an issue.

let looks_good = format!("{} > {} | : | :? | :#?", 2, 1);
let looks_off = format!("{:?} > {:#?}", 2, 1);

The highlighting does not reflect that "{}", "{:?}" and "{:#?}" are all interpolation symbols. In the Ayu themes ":" and "?" look like operators while "{", "}" and "#" look like part of the string. When not inside of curly braces they all look like normal characters in a string, which is correct. I have also loaded up Yarra Valley and the issue is clearer because Yarra Valley seems to be giving coloration specifically for interpolation symbols.

I don't know TextMate well but I think the "keyword.operator.key-value.rust" and "keyword.operator.question.rust" scopes are taking precedence over the "meta.interpolation.rust" scope, leaving "#" out because that is not an operator. It seems to be correct in labeling these as Rust interpolation symbols it's just the operator scope taking precedence that causes the issue.

From @a5hk in microsoft/vscode#120363

This issue is related to #108254 . Can we have keyword scope too? Something like this:

{
    "comment": "struct declarations",
    "match": "\\b(struct)\\s+([A-Z][A-Za-z0-9]*)\\b",
    "captures": {
        "1": {
            "name": "keyword.declaration.struct.rust storage.type.rust"
        },
        "2": {
            "name": "entity.name.type.struct.rust"
        }
    }
}

which results in:

I used the scope from https://www.sublimetext.com/docs/3/scope_naming.html#storage.

string.quoted.double.rust used twice. Duplicate name.

Hello and happy holidays ☃️ Thank you for creating this grammar, and it's great to see it used within VSCode. I've come across what I think may be a bug within the syntax highlighting rules for procedural macros attributes that include lifetime. As an example, take the following code snippet...

#[derive(Foo)]
#[foo('a)]
struct Bar<'a> { ... }

Whilst in GitHub none of the foo('a) is highlighted, this grammar highlights everything after the ' as I presume it is mistaking this as the start of a quotation rather than as a lifetime. Since the 'quotation' is never ended, it then highlights a)] as well as the entirety of the next line too. In fact, it seems it will keep highlighting the rest of the file until another lifetime (i.e. a closing ') is found! The problem can also be extended to slightly more complex examples such as #[foo('a, A)] and #[foo('a, 'b)] (the second of which it will just highlight a, ).

I would have tried to create a test case for this but I'm not quite sure what the intended behaviour is here. Both GitHub and the Rust playground seem to not highlight any kind of attribute or derive macros at all as far as I can tell, whereas this grammar will highlight the Copy within a #[derive(Copy)] for instance.

In case it helps, and just to motivate why there might be lifetimes like this within attribute macros, I thought I'd explain the context in which I ran into this. Let's say I create a trait Foo that looks something like this...

trait Foo<'a> { ... }

I may then want to create a derive macro in order to implement the trait. However, the macro wouldn't know which lifetime to use for 'a when implementing for a struct which itself multiple lifetime. Therefore, as shown above, a derive macro helper attribute would probably be added for the user to specify this lifetime.

I hope this is useful, I'd be really happy to spend some more time investigating if that would help at all!

"patterns": [ { "include": "#keywords" } ] does not work with "match"
it currently doesn't do anything and can be safely removed

Traits and enums are only assigned the entity.name.type.trait and entity.name.type.enum scopes in their declaration. This isn't very useful since it doesn't actually apply to the usage of the types, where being able to identify by color would be much more useful. In usage, they instead get entity.name.type.other. So it's disorienting because you might think that traits are supposed to be green, but it's yellow when used so you think it's a struct instead. The declaration and usage need to be consistent. I've just made them all the same color in my theme to avoid confusion from inconsistency.

Some new scopes would be nice as well:

See microsoft/vscode#108254 (comment) (and rust-lang/rust-analyzer#6137 (comment)).

This does affect even more keywords (other than fn and use):

...
{
                    "comment": "control flow keywords",
                    "name": "keyword.control.rust",
                    "match": "\\b(async|await|break|continue|do|else|for|if|loop|match|move|return|try|where|while|yield)\\b"
                },
...

move and where do not cause control-flow either.

Also this:

contradicts:

EDIT: The same applies to the async keyword, it doesn't cause control-flow, it's merely a specifier/modifier.

The for keyword may not be used as a control-flow keyword, as it can be used in hrtb context (for<'a> ...). Howver, I am not quite sure how the old grammar dealt with that.

Shouldn't things like String, i32 have storage.type or maybe support.type scope instead of entity.name.type?

Currently a function definition seems to have the same token as a function call.
I find it useful to have these differently colored, if possible could a token be provided for each?

So Attributes within the type are not highlighted. However, if I do try to highlight it applies to their parameters too.

Is it possible to make attributes have one scope?

Then the param keywords have another scope?

Type: Bug

In strings in Rust, \xN8 and \xN9 (N = 0-7) are colored incorrectly.
Although these characters escaped ASCII characters, they are not scoped as such:

vs.

Originally from @noritada in microsoft/vscode#166781

The "weak keyword" (see https://doc.rust-lang.org/reference/keywords.html#weak-keywords) union when used in the context of the function HashSet::union, sometimes receives erroneous highlighting.

Problematic code sample

use std::collections::HashSet;

fn main() {
    let set_a = HashSet::from([0, 1]);
    let set_b = HashSet::from([2, 3]);

    let set_c: HashSet<_> = set_a.union(&set_b).collect();
    dbg!(set_c);

    let set_d: HashSet<_> = [set_a, set_b]
        .into_iter()
        .reduce(|acc, set| acc.union(&set).cloned().collect())
        .unwrap();
    dbg!(set_d);
}

Observe that the two calls to HashSet::union are highlighted differently.

P.S. This issue was originally raised here: microsoft/vscode#141141

From @KSXGitHub

Comments are pieces of code that is usually ignored and can be placed anywhere. Doc comments in most languages are usually ignored by the compiler/interpreter. But Rust's so-called "doc comments" are different from normal comments:

• Under every outer doc (/// ..., /** ... */, or #[doc = "..."]) must be a language item. Otherwise, it is a syntax error.
• Every inner doc (//! ..., /*! ... */, or #![doc = "..."]) must be placed within a language item. Otherwise, it is a syntax error.
• Doc comment is just syntactic sugar for the #[doc] attribute.

Suggestion

Doc comment in Rust is a flavor of Markdown, therefore it should be highlighted as a Markdown code snippet.

Hi @dustypomerleau ,

First of all, THANK YOU !
Thanks to you, to this repo and your theme Tol, I have an amazing experience developping Rust code in VsCode. (Same goes for the other Rust dev on VsCode I am sure.)

Now, the question, is this repo still maintained? According to the README.md:

This extension provides a TextMate grammar for Rust. In most cases, you won't need to install the extension, as this repository is upstreamed by VS Code (issues and PRs should be submitted here).

And as I can see in the vscode repo, @alexr00 redericted people here for the issues and PRs.

Looking at the Issues, there are 9 open without any discussion/feedback. For more than a year, almost 2.
Those issues are relevant though...

Looking at the Pull request there are 6 open without any discussion/feedback. (1 for a year and the 5 others are more recents I admit).

I would love to see those PR merged and issues resolved.

@dustypomerleau, can you please comment if you are still willing to maintain this repo that the Rust community on VsCode use ? Or do you want to find another maintainer ?

The syntax highlighting for floats is incorrect:

*const Self is marked as constant.other.caps.rust but *mut Self is correct(variable.language.self.rust).

I noticed that in macros syntax when the parameters are defined with a whitespace after : it is not scoped as metavariable.specifier

To reproduce

macro_rules! my macro {
    ($a:tt $b: tt) => ()
}

Image:

The first tt is scoped as metavariable.specifier, while the second is not.

I'm using the lastest version that comes with rust-analyzer

I installed this extension because I thought the default Rust syntax highlighting was lacking in VS Code, but I can't figure out how to get VS Code to use it. I also have the official rust-analyzer extension installed, and I saw #1, but I'm confused as to how to change the grammar association for Rust. I tried disabling the VS Code builtin Rust syntax extension, but now Rust files have no highlighting at all. Any ideas?

Unlike '-=', '/=' and other similar operators, '+=' does not seem to have the correct scope. Only the '=' part in the '+=' operator seems to work, meanwhile the '+' part just has the default 'source.rust' scope. It seems to be an oversight with the TextMate JSON grammar file, as when I checked to see if it was being matched along with the other assignment operators, I could not find it.