[Rust] structs failing to highlight properly with field attributes

[envp]

Source of issue

VSCode extension

What was expected

Consistent syntax highlighting within structs that have field attributes, for the following code:

The code in question:

#[derive(StructOpt)]
#[structopt(name = "logan", about = "Match, parse, and transform your logs")]
pub struct ProgramOptions {
    /// Run the tool in debug mode. Copious amounts of information will be
    /// dumped to stderr
    #[structopt(short)]
    pub debug: bool,

    /// Pattern to search for, syntax is similar to perl regexes
    #[structopt(short, name="REGEX", parse(from_str=parse_regex))]
    pub pattern: Regex,

    /// Source of input lines, defaults to stdin
    #[structopt(
        short,
        name = "INFILE",
        default_value="-",
        parse(from_os_str=parse_istream_path)
    )]
    pub input: Box<dyn std::io::Read>,

    /// Sink for results, defaults to stdout
    #[structopt(
        short,
        name = "OUTFILE",
        default_value = "-",
        parse(from_os_str=parse_ostream_path)
    )]
    pub output: Box<dyn std::io::Write>,
}

What was observed:

The attribute markers seem to trip up the highlighter, with it failing to highlight the field attributes after the 2nd item, here's some screenshots where I progressively delete the markers. The final one seems to "expected"

Original issue

Test 1: Delete the last decorator, the same issue moves 1 field up

Test 2: This seems to be working as expected.

[EvgeniyPeshkov]

Hello @envp .

I've found where the problem is. I'm not very familiar with Rust, so forgive me if I am not quite accurate.

The issue is with meta item. It seems that tree-sitter-rust follows the specification and requires right part to be literal . So expressions like from_str=parse_regex breaks syntax parser.

If we replace e.g. parse_regex by "parse_regex" (string instead of what looks like variable/constant/property) everything will work as expected.

So highlighting is broken not by field attributes, but only after from_str=parse_regex item and until next recovery poit that is }.

[envp]

Ah, I see. Thanks for the clarifying link. I haven't gone through it yet, but I'm commenting here so I don't miss the notification. Will get back to you on this.