Problem with .C files being associated with C instead of C++ with 0.26.1 #4632

sean-mcmanus · 2019-11-18T23:14:43Z

I seem to be having a similar issue on my system. I am working on a C++ project and the extension does not seem to be handling C++ syntax properly, as people have mentioned above in this issue. I have been manually reverting the C++ extension back to version 0.24.1, as that seems to be the most recent extension version where the problem does not occur.

I ran the C/C++: Log Diagnostics command on both versions of the extension, and I've noticed that the Standard Version is different for the same translation unit. I have redacted some project-specific information (includes, source file names) from the output, as it may be confidential and I don't feel comfortable sharing it.

-------- Diagnostics - 11/18/2019, 12:40:23 PM
Version: 0.26.1
Current Configuration:
{
    "name": "Linux",
    "includePath": [
        "${workspaceFolder}/src/include",
        "${workspaceFolder}/src",
        "/usr/include/x86_64-linux-gnu/c++/7",
        "/usr/include/c++/7"
    ],
    "defines": [],
    "compilerPath": "/usr/bin/gcc",
    "cStandard": "c11",
    "cppStandard": "c++11",
    "intelliSenseMode": "${default}",
    "compilerArgs": []
}
Translation Unit Mappings:
[ <REDACTED>.C ]:
    <REDACTED>.H
Translation Unit Configurations:
[ <REDACTED>.C ]:
    Process ID: 834
    Memory Usage: 29 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        <REDACTED - workspace include path>
        <REDACTED - workspace include path>
        /usr/include/x86_64-linux-gnu/c++/7
        /usr/include/c++/7
        /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
        <REDACTED - translation unit-specific include path>
    Standard Version: c11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=70400
Total Memory Usage: 29 MB

The output for version 0.24.1 is almost identical, but the Standard Version is c++11 instead of c11. Is it possible that the 0.26.1 version of the extension is treating the C++ source files as C source files instead? I thought that might explain why it seems C++ specific syntax is not being handled properly. Our naming conventions for our C++ source and header files are somewhat abnormal (.C/.H), but it doesn't seem like this was a problem in earlier versions of the extension. I have the language mode set to C++ for these filename extensions, and I've verified that the language mode setting for this specific translation unit is C++ (not sure if that makes a difference)

Originally posted by @bwarrum-ibm in #4614 (comment)

The text was updated successfully, but these errors were encountered:

sean-mcmanus · 2019-11-18T23:16:57Z

VS Code itself isn't able to differentiate between the ".c" and ".C" so we have code that should add the sourceFile.C to your files.associations setting in your workspace. Do you see that setting added? If not, what happens when you add it manually for that file?

sean-mcmanus · 2019-11-18T23:23:19Z

Also, unrelated to the c11 issue, but you should remove the system includes from your includePath (it could cause incorrect include path ordering with the other system includes obtained from the compilerPath).

ghost · 2019-11-19T00:14:33Z

@sean-mcmanus Thanks for responding. The problem does appear to be related to the files.associations setting in my workspace.

The file association for that particular translation unit was missing on extension version 0.26.1. When I reverted back to version 0.24.1, the extension automatically added the file association for that specific translation unit in my workspace settings.json. Upgrading to 0.26.1 with the file association still present fixed the issues I was seeing.

I also tried reverting back to 0.24.1 and removing the file association manually before upgrading. After the upgrade to 0.26.1, the file association was not automatically added, and I saw the same issues. Adding the file association manually after upgrading to 0.26.1 resolved the problems.

The reason I had the system includes manually defined in my includePath was that C++ standard library headers were not being detected. I was seeing errors like this:

#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit (<REDACTED>.C).C/C++(1696)
cannot open source file "iostream" (dependency of "<REDACTED>.H")C/C++(1696)

I think these two problems are related. If the file association is not updated properly for a translation unit, and the C++ extension uses the c11 standard instead of C++11 standard, then the compiler does not report the C++ standard library include paths. Here's the Log Diagnostics output after removing the manually-defined entries from includePath:

Version: 0.26.1
Current Configuration:
{
    "name": "Linux",
    "includePath": [
        "${workspaceFolder}/src/include",
        "${workspaceFolder}/src"
    ],
    "defines": [],
    "compilerPath": "/usr/bin/gcc",
    "cStandard": "c11",
    "cppStandard": "c++11",
    "intelliSenseMode": "gcc-x64",
    "compilerArgs": [],
    "browse": {
        "path": [
            "${workspaceFolder}/src/include",
            "${workspaceFolder}/src",
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ <REDACTED>.C ]:
    <REDACTED>.H
Translation Unit Configurations:
[ <REDACTED>.C ]:
    Process ID: 4169
    Memory Usage: 11 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        <WORKSPACE_FOLDER>/src/include
        <WORKSPACE_FOLDER>/src
        /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
        <REDACTED - translation unit-specific path>
    Standard Version: c11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=70400
Total Memory Usage: 11 MB

Note that the Standard Version is c11 and none of the C++ standard library headers are present in the include list. Manually adding the cpp file association for this translation unit changes the standard version, and as a result the correct standard c++ include paths are used without changing the configuration:

Translation Unit Mappings:
[ <REDACTED>.C ]:
    <REDACTED>.H
Translation Unit Configurations:
[ <REDACTED>.C ]:
    Process ID: 5173
    Memory Usage: 118 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        <WORKSPACE_FOLDER>/src/include
        <WORKSPACE_FOLDER>/src
        /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
        <REDACTED - translation unit-specific path>
    Standard Version: c++11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --g++
        --gnu_version=70400
Total Memory Usage: 118 MB

So I guess the remaining question is why the file associations are not being updated properly in 0.26.1? Please let me know if you need any additional information

ghost · 2019-11-19T00:20:27Z

I should also mention that I already have wildcard file associations in my workspace settings that should apply to all files with .C and .H extensions.

    "files.associations": {
        "*.bats": "shellscript",
        "*.C": "cpp",
        "*.H": "cpp",
        ...
     }

sean-mcmanus · 2019-11-19T00:29:15Z

Yeah, the "*.C" association should work (it'll just apply to "*.c" as well, since it's case insensitive), so in that case it shouldn't add the "file.C" association. Are you saying the "*.C" association isn't working?

ghost · 2019-11-19T00:54:52Z

Well, I used to have an association that looked like this:
"*.[CH]": "cpp"

I thought this was valid syntax, but it seems like on version 0.24.1, the extension was adding specific file associations for each one of my .C files. After moving to 0.26.1, those filename-specific associations were not being added by the extension anymore, and that was causing the problems.

I just recently (within the past hour, as I was trying to reproduce) changed that association to look like this:

"*.C": "cpp",
"*.H": "cpp"

I was still seeing some issues immediately after the change, but this time I fully closed and restarted VS code after making the change, and I haven't been able to reproduce any problems in 0.26.1 since then.

sean-mcmanus · 2019-11-19T01:06:57Z

Oh, that sounds good. Let us know if you still encounter a problem.

ghost · 2019-11-19T23:40:05Z

@sean-mcmanus After making the changes I mentioned above to the files.associations setting, I've still been periodically encountering issues where C++ standard library includes are not being recognized.

I was able to reproduce include errors 100% of the time with some specific files in my project directory. I've since narrowed it down to a very small workspace configuration which still reproduces the error every time on my system. I've attached a .tar.gz containing the files for this minimal workspace.
vscode-cpptools-issue-4632.tar.gz

I'm running VSCode on Windows 10, but I'm using the Remote - WSL extension to open the project in a WSL environment.

Steps I take to recreate:

Extract the archive and open the directory in VSCode using the Remote - WSL extension
Ensure there are no files open in the editor.
Run Developer: Reload Window
Open only src/a/b/B.H (do not open any other files first)

Repeating steps 2-4 yields the same results.
Every time I've done this so far, I get this error message in B.H:

#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit (/home/bwarrum/projects/vscode-cpptools-issue-4632/src/a/c/A.C).C/C++(1696)
cannot open source file "cstdint"C/C++(1696)

Results of running C/C++: Log Diagnostics directly after opening B.H:

-------- Diagnostics - 11/19/2019, 5:12:37 PM
Version: 0.26.1
Current Configuration:
{
    "name": "Linux",
    "includePath": [
        "${workspaceFolder}/src"
    ],
    "defines": [],
    "compilerPath": "/usr/bin/gcc",
    "cStandard": "c11",
    "cppStandard": "c++11",
    "intelliSenseMode": "gcc-x64",
    "compilerArgs": [],
    "browse": {
        "path": [
            "${workspaceFolder}/src",
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ /home/bwarrum/projects/vscode-cpptools-issue-4632/src/a/c/A.C ]:
    /home/bwarrum/projects/vscode-cpptools-issue-4632/src/a/b/B.H
Translation Unit Configurations:
[ /home/bwarrum/projects/vscode-cpptools-issue-4632/src/a/c/A.C ]:
    Process ID: 8014
    Memory Usage: 7 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        /home/bwarrum/projects/vscode-cpptools-issue-4632/src
        /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/bwarrum/projects/vscode-cpptools-issue-4632/src/a/b
    Standard Version: c11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=70400
Total Memory Usage: 7 MB

The C++ extension is still using the c11 standard version for this file instead of C++11, even though the files.associations property in settings.json has wildcards that specify all .C and .H files are C++.

Interestingly enough, the C++ extension works perfectly fine if I follow the following steps:

Extract the archive and open the directory in VSCode using the Remote - WSL extension
Ensure there are no files open in the editor.
Run Developer: Reload Window
Open only src/a/c/A.C (do not open any other files first)
Navigate to any source file in the project after this point and no include errors appear

This project (although contrived) does build and run successfully by running make in the src directory and running ./Test

Colengms · 2019-11-20T00:14:55Z

Hi @bwarrum-ibm . It looks like we are not handing ".H" files as C++. File associations are based on the name of the file that was opened, not the file selected to use for the translation unit, unfortunately.

This should be fixed by: #4639

ghost · 2019-11-22T21:33:33Z

I'm still seeing some issues with this on 0.26.2-insiders2. (I think the fix for this went into the 0.26.2-insiders2 release, apologies if I'm mistaken). Seeing the same sort of issue as before, where the incorrect standard version is being applied for C++ source files, and the C++ standard library header files are not added to the include path. Here are the Log Diagnostics (I've edited some directory and source file names due to confidentiality, but all the file extensions in the output are the same)

-------- Diagnostics - 11/22/2019, 3:21:13 PM
Version: 0.26.2-insiders2
Current Configuration:
{
    "name": "Linux",
    "includePath": [
        "${workspaceFolder}/src/include",
        "${workspaceFolder}/src"
    ],
    "defines": [],
    "compilerPath": "/usr/bin/gcc",
    "cStandard": "c11",
    "cppStandard": "c++11",
    "intelliSenseMode": "gcc-x64",
    "compilerArgs": [],
    "browse": {
        "path": [
            "${workspaceFolder}/src/include",
            "${workspaceFolder}/src",
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ <WORKSPACE>/src/a/b/File.C ]:
    <WORKSPACE>/src/a/b/File.H
Translation Unit Configurations:
[ <WORKSPACE>/src/a/b/File.C ]:
    Process ID: 2091
    Memory Usage: 10 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        <WORKSPACE>/src/include
        <WORKSPACE>/src
        /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
        <WORKSPACE>/src/a/b
    Standard Version: c11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=70400
Total Memory Usage: 10 MB

And files.associations from my workspace settings.json:

    "files.associations": {
        "*.bats": "shellscript",
        "*.C": "cpp",
        "*.H": "cpp",
        "condition_variable": "cpp",
        "type_traits": "cpp"
    },

sean-mcmanus · 2019-11-23T00:01:28Z

Yeah, sorry about the confusion -- I still repro the bug.

Colengms · 2019-11-23T02:27:28Z

Hi @bwarrum-ibm . It looks like there were multiple issues here. We have a fix ready to go out in the next release, and have confirmed it against your repro. :)

Colengms · 2019-11-26T02:17:05Z

Hi @bwarrum-ibm . Your repro should be addressed by 0.26.2-insiders3.

sean-mcmanus closed this as completed Nov 19, 2019

Colengms reopened this Nov 20, 2019

sean-mcmanus removed more info needed The issue report is not actionable in its current state not reproing We're not able to reproduce the issue (it's unlikely to get fixed until we find one). labels Nov 20, 2019

sean-mcmanus assigned Colengms Nov 20, 2019

sean-mcmanus added this to the 0.26.2 milestone Nov 20, 2019

Colengms added the fixed Check the Milestone for the release in which the fix is or will be available. label Nov 21, 2019

sean-mcmanus removed the fixed Check the Milestone for the release in which the fix is or will be available. label Nov 22, 2019

sean-mcmanus added the fixed Check the Milestone for the release in which the fix is or will be available. label Nov 26, 2019

michelleangela closed this as completed Dec 3, 2019

ghost mentioned this issue Jun 5, 2020

.C files being associated with C instead of C++ in 0.28.2 #5618

Closed

github-actions bot locked and limited conversation to collaborators Oct 8, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Problem with .C files being associated with C instead of C++ with 0.26.1 #4632

Problem with .C files being associated with C instead of C++ with 0.26.1 #4632

sean-mcmanus commented Nov 18, 2019

sean-mcmanus commented Nov 18, 2019

sean-mcmanus commented Nov 18, 2019

ghost commented Nov 19, 2019 •

edited by ghost

Loading

ghost commented Nov 19, 2019

sean-mcmanus commented Nov 19, 2019 •

edited

Loading

ghost commented Nov 19, 2019

sean-mcmanus commented Nov 19, 2019

ghost commented Nov 19, 2019

Colengms commented Nov 20, 2019

ghost commented Nov 22, 2019

sean-mcmanus commented Nov 23, 2019

Colengms commented Nov 23, 2019

Colengms commented Nov 26, 2019

Problem with .C files being associated with C instead of C++ with 0.26.1 #4632

Problem with .C files being associated with C instead of C++ with 0.26.1 #4632

Comments

sean-mcmanus commented Nov 18, 2019

sean-mcmanus commented Nov 18, 2019

sean-mcmanus commented Nov 18, 2019

ghost commented Nov 19, 2019 • edited by ghost Loading

ghost commented Nov 19, 2019

sean-mcmanus commented Nov 19, 2019 • edited Loading

ghost commented Nov 19, 2019

sean-mcmanus commented Nov 19, 2019

ghost commented Nov 19, 2019

Colengms commented Nov 20, 2019

ghost commented Nov 22, 2019

sean-mcmanus commented Nov 23, 2019

Colengms commented Nov 23, 2019

Colengms commented Nov 26, 2019

ghost commented Nov 19, 2019 •

edited by ghost

Loading

sean-mcmanus commented Nov 19, 2019 •

edited

Loading