C file treated as C++ using Insiders build and SSH Remote extension, while working on a C codebase.

[sean-mcmanus]

It seems that this is an issue again. This is using Insiders build and SSH Remote extension, while working on a C codebase.

Originally posted by @anatolyburakov in #1256 (comment)

[sean-mcmanus]

@anatolyburakov Can you use the C/C++: Log Diagnostics command to see what language is being used for IntelliSense? Can you also check your files.associations setting?

Do you know if this is a regression with 0.25.0-insiders (compared to 0.24.1)?

[anatolyburakov]

I'm currently trialling VSCode to see if it works for me so i cannot say if it's a regression - i haven't used previous insiders builds.

Doing more digging, i can reproduce this the following way:

1. everything at default settings => .c file is parsed as a C++ file
2. add association to "c" in the settings.json => .c file is shown as a C file, but still parsed as C++
3. add association to "c" and edit the compiler field (for example, switch from gcc to clang and back) => everything works correctly now

So the error seems to come from the C++ extension not fully updating the code model after changing the file association. Of course, the fact that a .c file is parsed as a C++ file by default is a bug in itself IMO, and editing file associations shouldn't be needed.

[sean-mcmanus]

I'm not able to reproduce any of the issues you are describing. I see ".c" files being parsed as C files and not C++. Did you try the C/C++: Log Diagnostics command to see what "Standard Version" is being used, i.e. c99?

By "Insiders build" do you mean the VS Code Insiders or the C/C++ Insiders? You can try the non-Insiders build of our extension via setting C_Cpp.updateChannel to "Default".

[anatolyburakov]

When i say "insiders build" i mean VSCode Insiders - for the extension itself, the update channel is set to "default". I'm also using Remote SSH extension - are you doing that as well when you're reproducing it?

I can reproduce the issue every time.

Here's the diagnostics logs from opening one of the files:

-------- Diagnostics - 8/14/2019, 10:15:19 AM
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/eal_common_memalloc.c]:
    /home/anatoly/DPDK/lib/librte_eal/common/eal_common_memalloc.c
Translation Unit Configurations:
[/home/anatoly/DPDK/lib/librte_eal/common/eal_common_memalloc.c]:
    Process ID: 81360
    Memory Usage: 18 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        /usr/include/c++/7
        /usr/include/x86_64-linux-gnu/c++/7
        /usr/include/c++/7/backward
        /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/home/anatoly/build
        /home/anatoly/DPDK/lib/librte_eal/linux/eal/include
    Defines:
        _GNU_SOURCE
    Forced Includes:
        /home/anatoly/DPDK/config/rte_config.h
    Standard Version: c++17
    IntelliSense Mode: gcc-x64
    Other Flags:
        --g++
        --gnu_version=70400
Total Memory Usage: 18 MB

This is with associations commented out. When enabling associations and reloading the window, everything works fine. I was under the impression that changes took place immediately, but apparently i have to reload the file for changes to take effect.

For reference, the codebase i'm working on is DPDK so you may want to test with this specific codebase to see if it helps reproducing the issue.

[sean-mcmanus]

Yeah, I'm not able to repro this with the SSH extension...I don't know what could be different. I don't see how this could occur from reviewing the code either.

@Colengms @michelleangela @bobbrow Any ideas how to get a repro?

[konradsa]

@sean-mcmanus I am having a similar, possibly related issue. I am using the latest main release 1.39.2 and the latest Remote SSH extension to connect to a Linux host. When not using a compile_commands.json file, Intellisense is doing okay, but not very accurate. Trying to make it more accurate with a compile_commands.json though causes many the *.C files I have to be parsed as C instead of C++. The editor shows a C++ in the tab on top, but when I look at the C++ debug log it's using c11, and gives me the obvious error that "identified namespace is undefined".

I tried to force the *.C association to be cpp, but no avail. The weird thing is that it seems to be somewhat random, parses correctly as C++14 for some files, and other times if falls backs to C11 (even for files it used C++14 before) and fails then.

Any idea what could be causing this? My compile_commands.json is pretty large, ~23,000 entries. Also can you tell me what exactly is VSCode looking for in the compile_commands.json to determine the C/C++ std, and what could be interfering with it?

Thanks

[sean-mcmanus]

@konradsa Our compile commands code just checks if the document is a C or C++ file based on the files.associations. The same code path should be hit for compile commands and non-compile commands. I.e. I don't know what is causing that. Your issue appears to be the opposite of the reported bug though.

[FlorentRevest]

I am having the same issue working on the Linux kernel over SSH.
.c files are recognized as "C" in the bottom blue bar. They also have a "C" icon in the explorer panel. However, when running the log diagnostic, this extension reports using the C++20 standard and enables the -g++ option.

[FlorentRevest]

Oh I actually just found out what was happening on my machine. In my case, having "ccache gcc" in compile_commands.json resulted in IntelliSense parsing files as C++. replacing all "ccache gcc" with "gcc" and waiting for the indexing to be done fixed IntelliSense parsing of C files
EDIT: meh it briefly worked but already stopped working

[konradsa]

@FlorentRevest I gave up on intellisense, was not able to fix it. I switched to vscode-clangd together with a compilation database, and even though it has its own issues, overall it works much better.

[FlorentRevest]

Thanks for the tip @konradsa I tried vscode-clangd out and it indeed solves all of my problems! :)

[bobbrow]

@anatolyburakov is this still an issue for you in the latest version of the extension? We don't have the information we need to proceed with the investigation at this point, so if you are still seeing it and have anything else you can share (maybe your VS Code settings as well), that would help us investigate. Otherwise, we will close this issue.

@FlorentRevest and @konradsa, I'm sorry that you had trouble configuring the extension. We should be supporting *.C as c++ correctly in the latest version of the extension. If the ccache gcc command is still tripping up, can you open a new issue for us to investigate?

Thank you!

[sean-mcmanus]

FYI, we've fixed a couple issues with .C being associated with C instead of C++ for our next release, not sure if that's related to this issue: #5618 .

[anatolyburakov]

@sean-mcmanus @bobbrow i haven't seen any issues in a while because i had things manually associated in my settings.json, but i've just commented it out, and the sky hasn't fallen so far. so i take it the original issue was fixed, at least for me :)

however, there probably is still a potential issue with .h files, as they are recognized as C++ files by default. i think maybe only recognizing .hpp files as C++ headers would be better?

[sean-mcmanus]

@anatolyburakov .h being associated with C++ by default is "by design" (.h is used by C++ more frequently than .hpp is used). That can be changed by setting "*.h": "c" in files.associations (and then doing a Reloading Window to get around the bug at #5618 ). However, it looks like it's possible we could add code that automatically adds ".h": "c" associations when headers are navigated to from "c" associated files, like what we currently do for extensionless files.

[bobbrow]

If navigating to a .h file from a .c file, the language server should be operating in C-mode even if VS Code says it's a C++ file. Right @sean-mcmanus?

[sean-mcmanus]

@bobbrow Yes, the IntelliSense engine for the TU would be in C mode, assuming it doesn't go to a header only fallback for some other reason.

[anatolyburakov]

@sean-mcmanus that would be great. if IntelliSense keeps track of what files include what other files, that'd fix the problem. one thing i'm concerned about is that we sometimes include C headers from C++ code, so if both C and C++ files include another file (within the same project, of course), IMO it should default to C as the lowest common denominator.

that said, i never had any issues since setting up the associations manually, so the above suggestion is not urgent to implement as far as i'm concerned.

[bobbrow]

I created #5689 to cover @sean-mcmanus's idea. We will track upvotes on it to determine its priority. I will close this issue. Thank you!