[[attributes]] break syntax highlighting until {

[matter123]

Similar to #37 after a C++ attribute [[fallthrough]],[[nodiscard]], etc. Syntax highlighting breaks until {.

Example

switch(test) {
	case 1:
	break;
	case 2: [[fallthrough]];
	case 3: break; // no syntax highlighting
}
void func1();
[[noreturn]] void func2(/*syntax highlighting*/); // no syntax highlighting
struct st { // syntax highlighting works now
};
void func3();

Image:

[matter123]

[[attributes]] are technically ambiguous as
foo[[]{return funcReturningVector();}()[0]] is a valid expression. But attributes are far more comman than a self executing lambda inside a subscript operator.

[jeff-hykin]

Putting this here just for reference:
https://en.cppreference.com/w/cpp/language/attributes

I think the best way to match it is going to be to create a pattern/range for it and then give it higher priority than lambdas. We might want to start with a pattern, especially since most cases seem to not contain a newline.

If a lambda inside of a subscript operator is the only situation where [[ is not an attribute, then I think we can safely create a range for attributes by just looking for [[ at the start and ]] at the end.

[matter123]

Found this quote on cppreference.com

Two consecutive left square bracket tokens ([[) may only appear when introducing an attribute-specifier or inside an attribute argument.

So the example I posted should above not be valid. However, attributes can be nested, so the rule should include itself to allow for that.

[jeff-hykin]

Great find 👍 It shouldn't be too hard to implement.

I need to focus on academics till the end of the semester so it might be awhile before I do any major contributions.

[matter123]

I came up with

#
# C++ Attributes
#
attributes = Range.new(
    repository_name: "attributes_cpp",
    tag_as: "support.other.attribute",
    start_pattern: newPattern(
        match: /\[\[/.or(/__attribute__\(\(/).or(/__declspec\(/),
        tag_as: "punctuation.start.attribute",
    ),
    end_pattern: newPattern(
        match: /\]\]/.or(/\)\)/).or(/\)/),
        tag_as: "punctuation.end.attribute",
    ),
    includes: [
        # allow nested attributes
        "#attributes_cpp",
        Range.new(
            start_pattern: newPattern(/\(/),
            end_pattern: newPattern(/\)/),
            includes: [
                "#strings_c",
            ],
        ),
        newPattern(match: /,/, tag_as: "punctuation.separator.attribute"),
        newPattern(match: /::/, tag_as: "punctuation.accessor.attribute"),
    ],
)

However, I can't seem to actually give it a higher priority than the lambda. Even when it is the first pattern, attributes are still tagged as lambdas.

Edit: after more looking if the attribute directly follows struct (but not class) than it is correctly tagged. Otherwise, it is still treated as a lambda.

[matter123]

It seems that function attributes in namespaces are the issue.

Image:

Unsurprisingly even without the issues caused by namespace, some patterns need to be adjusted to account for [[attributes]].

[jeff-hykin]

So I guess this will be decently hard to implement. If the C++ reference has enough documentation we can probably create a check list and gradually add it to each area one by one.

[matter123]

I've had some luck with an non greedy non range rule that includes the range rule. I'll make a PR later today to discuss specifics.

[peaceshi]

Same problem.

[matter123]

@peaceshi If you want a fix for some attributes you can copy the json file from #54 https://raw.githubusercontent.com/jeff-hykin/cpp-textmate-grammar/Fix-%2350/syntaxes/cpp.tmLanguage.json into {your vscode data dir}/extensions/jeff-hykin.better-cpp-syntax-1.6.8/syntaxes and reload.

Image: