@jeff-hykin , you seem to be the resident expert in VS Code's C++ Text Mate grammar. Would you be willing to review our choices of scopes in this document? Semantic tokens are not based on Text Mate grammar, and we've chosen these scopes solely to allow their colors to be specified by themes and settings.

I'd be happy to! I'm a little uncertain about what some things are referring to, is there a way I can run this to see what parts of the code this is being applied to? (edit: I didn't realize the language server was already available, I'm exploring it now)

For example "Class Template" I'm not sure if that means the template keyword in template<class T> class {}; or if it means the T

@jeff-hykin Class Template would refer to the type. "A" in the following example:

Generally speaking, these would be elements that there may not be sufficient context to identify syntactically, such as the second "A" which appears (I assume) in a position in which there is no longer knowledge of it having been a template class. There may be some contextual inconsistencies between Text Mate and VS IntelliSense. For example, in the above, perhaps TM would consider these 2 "A"'s differently, whereas VS IntelliSense will lump them into the same category.

Thanks!

| Token         | Scope         |
| ------------- |: -------------: |

| Event (C++/CLI)               | variable.other.event                        |
| Property (C++/CLI)            | variable.other.property                     |
| Generic Type (C++/CLI)        | entity.name.type.generic                    |
| Reference Type (C++/CLI)      | entity.name.type.reference                  |
| Value Type (C++/CLI)          | entity.name.type.class.value                |

| Member Operator               | punctuation.accessor                        |
| New / Delete                  | keyword.operator.new                        |
| Operator Function             | entity.name.operator                        |
| Function                      | entity.name.function                        |
| Member Function               | entity.name.function.member                 |
| Static Member Function        | entity.name.function.member.static          |
| Macro                         | entity.name.function.preprocessor           |
| Function Template             | entity.name.function.templated              |
| Label                         | entity.name.label                           |
| Type                          | entity.name.type                            |
| Class Template                | entity.name.type.class.templated            |
| User-Defined Literal - Raw    | entity.name.operator.custom-literal         |
| User-Defined Literal - Number | entity.name.operator.custom-literal.number  |
| User-Defined Literal - String | entity.name.operator.custom-literal.string  |
| Namespace                     | entity.name.namespace                       |
| Parameter                     | variable.parameter                          |
| Global Variable               | variable.other.global                       |
| Local Variable                | variable.other.local                        |
| Enumerator                    | variable.other.enummember                   |
| Member Field                  | variable.other.property                     |
| Static Member Field           | variable.other.property.static              |

I'm not sure what an event, property, reference type or value type are in C++ or where they are visible. I guess I'm not familiar with the C++/CLI.

The rest of the names should be blend in seamlessly with the rest of C++. The only challenging spots are places where the groups are more broad than the textmate groups. Here's a few examples of that difference:

The object access operator in C++ is punctuation.separator.dot-access and punctuation.separator.arrow-access, but Javascript uses punctuation.accessor, which is probably a more correct/useful name. I'll look into switching C++ to be punctuation.accessor.dot and punctuation.accessor.arrow for better cross-language cross-extension theming.

In Javascript and C++ the member access thing1.thing2.thing3
thing1 is tagged as variable.other.object.access
thing2 is tagged as variable.other.object.property
thing3 is tagged as variable.other.property
Different themes use those names to color the last/first or last and first variable in a chain of member accesses.

The custom literal syntax also seems to tag the operator keyword itself.

@jeff-hykin ,

variable.other.property

To differentiate a C++/CLI property from a member field, perhaps? :
variable.other.property.cli

punctuation.accessor

Member Operator would refer to any operator overloaded as member function. i.e.

class A
{
public:
   A& operator=(const A&);
   A& operator=(A&&);
   bool operator==(const A&) const;
   bool operator!=(const A&) const;
};

Would keyword.operator.member be more appropriate? Perhaps "Operator Overload Member" might a better name.

Thanks!

Function Operator looks to be similar to Member Operator, but for non-member overloads. Perhaps more accurately titled, "Operator Overload Function". Perhaps for these?

keyword.operator.overload.member
keyword.operator.overload.function

For Generic and Reference types, these are essentially classes.

https://docs.microsoft.com/en-us/cpp/extensions/generic-classes-cpp-cli?view=vs-2019
https://docs.microsoft.com/en-us/cpp/extensions/classes-and-structs-cpp-component-extensions?view=vs-2019

So, perhaps keep the '.class'?

entity.name.type.class.generic
entity.name.type.class.reference

I think variable.other.property.cli would fit in well

Operator Overloads

Ah, thank you for explaining the "Member Operator". Now looking at it in context, it makes much more sense that the C++ extension would be adding it for overloads rather than just picking a lone built in operator to add a scope too.

The operator overloads are definitely tough especially since textmate scopes do not allow for much description.

// function definition
string operator ^(const char* one, const char* two) {};

// function call
`std::operator ^("a", "c");`

The most accurate tags from my understanding would be tagging operator as keyword.other.operator and tag the the target as entity.name.function.operator or entity.name.function.operator.member.

I think using the keyword.operator (keyword.operator.overload.member) is a bit misleading since no operation is being performed, and instead a special syntax is being used for a function definition. If the syntax was messed up, like an operator overload that was missing the operator keyword, that's when the operator would be (and currently is) colored the keyword.operator color as if an operation was being performed.

Currently in the TextMate syntax the target of an operator overload is given entity.name.operator to give them a different color from both functions and operators, but I'd be okay adding entity.name.function.operator and entity.name.function.operator.member to the TextMate syntax for accuracy’s sake. Using entity.name.function.operator.member will have the downside of most theme's defaulting to the normal function color, although that might not be altogether bad.

Reference and Generic types

I'll take a look into it. I didn't realize C++/CLI was a superset syntax of C++. From what I understand reading so far, I think entity.name.type.class.generic and entity.name.type.class.reference would be accurate.