Semantic analysis doesn't understand struct names

[anatolyburakov]

I'm trying to customize VSCode's semantic syntax highlighting to be more like editors i am used to. I've hit the following issue:

As can be seen from the screenshot, the TM analysis shows that the editor doesn't understand that "malloc_elem" is a struct name, and thus doesn't attempt to colorize it in any way. This is despite the fact that autocomplete appears to be working for its members, so IntelliSense does know that it's a struct:

This is using VSCode Insiders build (CppTools extension is not Insiders build), on a Windows machine using CppTools on a remote machine over Remote SSH extension.

Diagnostic log from CppTools:

-------- Diagnostics - 8/14/2019, 10:27:20 PM
Version: 0.24.1
Current Configuration:
{
    "name": "Linux",
    "includePath": [
        "${workspaceFolder}/**",
        "${workspaceFolder}/../build/DPDK/**"
    ],
    "defines": [
        "_GNU_SOURCE"
    ],
    "compilerPath": "/usr/bin/gcc -Wall -Werror",
    "cStandard": "c99",
    "cppStandard": "c++17",
    "intelliSenseMode": "gcc-x64",
    "forcedInclude": [
        "${workspaceFolder}/config/rte_config.h"
    ],
    "browse": {
        "limitSymbolsToIncludedHeaders": false,
        "path": [
            "${workspaceFolder}/**",
            "${workspaceFolder}/../build/DPDK/**"
        ]
    }
}
Translation Unit Mappings:
[/home/anatoly/DPDK/lib/librte_eal/common/rte_malloc.c]:
    /home/anatoly/DPDK/lib/librte_eal/common/rte_malloc.c
Translation Unit Configurations:
[/home/anatoly/DPDK/lib/librte_eal/common/rte_malloc.c]:
    Process ID: 10699
    Memory Usage: 34 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        /usr/lib/gcc/x86_64-linux-gnu/7/include
        /usr/local/include
        /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
        /usr/include/x86_64-linux-gnu
        /usr/include
        /home/anatoly/DPDK/lib/librte_eal/common/include
        /home/anatoly/DPDK/lib/librte_eal/common/include/generic
        /home/anatoly/DPDK/config
        /home/anatoly/DPDK/lib/librte_eal/linux/eal/include
        /home/anatoly/build/DPDK
    Defines:
        _GNU_SOURCE
    Forced Includes:
        /home/anatoly/DPDK/config/rte_config.h
    Standard Version: c99
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=70400
Total Memory Usage: 34 MB

[matter123]

Developer: Inspect TM Scope shows the scopes from the textmate grammar. To customize the semantic colorization refer to https://code.visualstudio.com/docs/cpp/colorization-cpp.

[Colengms]

Hi @anatolyburakov . It looks like the TextMate (VS Code) grammar for C does not identify the struct with a scope (entity.name.type.*) as I would expect. That appears to work as expected in C++, and is handled entirely syntactically. C++ TextMate grammar matches it syntactically due to following the struct keyword. It should also be handled properly by the C/C++ extension's semantic colorization, regardless of whether in a .c or .cpp file.

Note that the "Inspect TM Scopes" command only reflects syntactic (TextMate) colorization, and does not reflect the scope name or color used by semantic colorization. Semantic colorization does appear to correctly color struct names (even in C files), using the style associated with the entity.name.type scope. Let me know if you are seeing otherwise.

[anatolyburakov]

@matter123 @Colengms OK, sure, but according to the page linked about colorization, struct type should be associated with "entity.name.type" and colorized accordingly. In my case, it should be colorized as magenta (#808), but it's not being colorized at all. However, if i hover over a variable of that type, the colorization works in the tooltip:

Again, this is using RemoteSSH extension and VSCode Insiders build (i've also switched CppTools to Insiders update channel just in case), maybe this is the culprit.

[Colengms]

Hi @anatolyburakov . I suspect you are seeing a limitation due to remoting. In that case, the extension runs on the remote machine where it does not have access to the theme, etc.. Could you confirm by trying this out with local code?

[anatolyburakov]

@Colengms yes, it appears to work locally. This is a bug then!

[sean-mcmanus]

I think we're tracking the bug with #3942 -- I think we're blocked by VS Code's lack of APIs.

[bobbrow]

Correct. This is #3942. We are working with the VS Code team to give us a more comprehensive API for colorization.