Struct members with a name that starts with a variable type get mis-categorized.

[alexr00]

From @LeandreBl here microsoft/vscode#76165
The problem does not occur when the file is tagged as a C++ file, only in C

Steps to Reproduce:

1. Write any line, in a C tagged file, with the syntax of a structure usage
2. For example

int main(void)
{
    im_a_struct.im_a_member = 0; /* works fine */
    im_a_struct.integer_member = 0; /* starts with a variable type "int", no color */
    im_a_struct.size_t_holder = 0; /* does not work too */
    im_a_struct.intra_thread = thread(); /* same issue, starts with "int" */
    im_a_struct.long_array = malloc(10000); /* "long" keyword */
}

The im_a_struct.im_a_member line gets additional scopes (variable.other.object.access.c for im_a_struct and variable.other.member.c for im_a_member) but the lines below it just have meta.block.c.

[jeff-hykin]

Thanks @matter123

@alexr00 the bounds were messed up so it was messed up for all the keywords, thankfully the one change fixes all of them.

@LeandreBl the initial fix has been push in v1.12.6, the change should show up in a later version of VS Code. If you want the fix right now download the Better Syntax extension and it will automatically be applied

[jeff-hykin]

The bad news is @matter123 I just realized size_t actually can be a member 😓
The following code outputs "10" on gcc/clang

struct A {
    int size_t = 10;
};
int main(int argc, char *argv[])
    {
        A a{10};
        cout << a.size_t << "\n";
        return 0;
    }

I'm not sure if this is in accordance with the language spec, and I'm not sure which types it applies to. Whatever types it does apply to, I'd say initially lets assume its a type unless it's preceded with a member access operator, meaning it would still be marked incorrectly inside of the struct. We'll have to wait till after variable declares/definitions are working before fixing it inside of structs.

[matter123]

The C11 standard in 7.1.3/1.4 (N1570) explicitly says that any symbols with external linkage (rather than static linkage) are reserved. The definition of the header <stddef.h> does not say that size_t has static linkage. 7.19/2. Therefore the use of size_t as anything other than what <stddef.h> defines it as, violates the C standard.

[jeff-hykin]

Ah okay excellent. Your knowledge of the standard is impeccable as usual 👍

[matter123]

C++ has a similar requirement in [extern.names]/3

Each name from the C standard library declared with external linkage is reserved to the implementation for use as a name with extern "C" linkage, both in namespace std and in the global namespace.