Repository navigation
Problem with .C files being associated with C instead of C++ with 0.26.1 #4632
Description
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)
Activity
sean-mcmanus commentedon Nov 18, 2019
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 commentedon Nov 18, 2019
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).
sean-mcmanus commentedon Nov 19, 2019
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?sean-mcmanus commentedon Nov 19, 2019
Oh, that sounds good. Let us know if you still encounter a problem.
Colengms commentedon Nov 20, 2019
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
sean-mcmanus commentedon Nov 23, 2019
Yeah, sorry about the confusion -- I still repro the bug.
Colengms commentedon Nov 23, 2019
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 commentedon Nov 26, 2019
Hi @bwarrum-ibm . Your repro should be addressed by 0.26.2-insiders3.