If using SSH remote, specify OS of remote machine: N/A
Bug Summary and Steps to Reproduce
Bug Summary:
Our development environment involves opening files that are symlinks to files with "odd" file extensions. One contrived example:
/path/to/file/Test.C: symbolic link to /other/path/to/file/cur,Test.C,1.1^123
When opening either the symlink or the actual file, VSCode starts with a Language Mode of C++. But after some time automatically (or after making a small edit to the file), it will revert to a Language Mode of C. Even if I manually change the Language Mode back to C++, it will still revert to C later. These files are C++ source files, so the C++ start is correct. Reverting to C causes incorrect syntax highlighting and false positives for compiler errors. Making a copy of the file to a different place without the odd part at the end of the file causes the Language Mode of the editor to stay on C++. So there is something odd about the extension of the actual file.
I have tried adding the following to my user settings to see if that would make a difference, but while it did get VSCode to recognize both files a C++ files without manual intervention initially, it still ended up reverting back to C at some point:
Changing the state of C_Cpp.autoAddFileAssociations did not seem to make any difference. Also, this issue did not occur with the "C_Cpp.intelliSenseEngine": "Tag Parser" setting (it stayed on C++ Language Mode for both the symlink and the actual file). So it appears to be something with the default IntelliSense engine.
Steps to reproduce:
Open a stock VSCode instance with only the C/C++ extension installed, and default settings for everything.
Create a file like Test.C,1.1^123, make it a simple "Hello World" like the below:
3. If the Language Mode is not C++, manually change it to C++.
4. After a bit of time, you should see the Language Mode change to C. If not, make a small edit to the file.
5. The Language Mode should now be reverted to C. This issue should repeat indefinitely even if manually changed back to C++.
**Expected behavior:**
The Language Mode should not automatically revert to C, even after manually changed by the user to C++.
### Configuration and Logs
```shell
NO C_CPP_PROPERTIES.JSON FILE EXISTS, DEFAULTS USED.
C/C++: LOG DIAGNOSTICS OUTPUT (macOS)
-------------------------------------
-------- Diagnostics - 7/11/2024, 5:50:09 PM
Version: 1.20.5
Current Configuration:
{
"name": "Mac",
"includePath": [
"/Users/parker/vscode/cppbugtest/user/**"
],
"defines": [],
"macFrameworkPath": [
"/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks"
],
"compilerPath": "/usr/bin/clang",
"cStandard": "c17",
"cppStandard": "c++17",
"intelliSenseMode": "macos-clang-x64",
"compilerPathInCppPropertiesJson": "/usr/bin/clang",
"intelliSenseModeIsExplicit": false,
"cStandardIsExplicit": false,
"cppStandardIsExplicit": false,
"mergeConfigurations": false,
"compilerPathIsExplicit": false,
"browse": {
"path": [
"/Users/parker/vscode/cppbugtest/user/**",
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true
}
}
cpptools version (native): 1.20.5.0
Translation Unit Mappings:
[ /Users/parker/vscode/cppbugtest/user/cur,Test.C,1.1^123 - source TU]:
Translation Unit Configurations:
[ /Users/parker/vscode/cppbugtest/user/cur,Test.C,1.1^123 ]:
Process ID: 25880
Memory Usage: 11 MB
Compiler Path: /usr/bin/clang
Includes:
/usr/local/include
/Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/include
/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include
/Library/Developer/CommandLineTools/usr/include
Frameworks:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/System/Library/Frameworks
Standard Version: c17
IntelliSense Mode: macos-clang-x64
Other Flags:
--clang
--clang_version=160000
Total Memory Usage: 11 MB
------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 10262
C/C++: LOG DIAGNOSTICS OUTPUT (RHEL)
------------------------------------
-------- Diagnostics - 7/11/2024, 5:52:35 PM
Version: 1.20.5
Current Configuration:
{
"name": "Linux",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [],
"compilerPath": "/bin/clang",
"cStandard": "c17",
"cppStandard": "c++14",
"intelliSenseMode": "linux-clang-x64",
"compilerPathInCppPropertiesJson": "/bin/clang",
"intelliSenseModeIsExplicit": false,
"cStandardIsExplicit": false,
"cppStandardIsExplicit": false,
"mergeConfigurations": false,
"compilerPathIsExplicit": false,
"browse": {
"path": [
"${workspaceFolder}/**"
],
"limitSymbolsToIncludedHeaders": true
}
}
cpptools version (native): 1.20.5.0
Translation Unit Mappings:
[ /tmp/Test.C,1.1^123 - source TU]:
Translation Unit Configurations:
[ /tmp/Test.C,1.1^123 ]:
Process ID: 2560643
Memory Usage: 16 MB
Compiler Path: /bin/clang
Includes:
/usr/lib64/clang/15.0.7/include
/usr/local/include
/usr/include
Standard Version: c17
IntelliSense Mode: linux-clang-x64
Other Flags:
--clang
--clang_version=150007
Total Memory Usage: 16 MB
------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 5202
Environment
Bug Summary and Steps to Reproduce
Bug Summary: Our development environment involves opening files that are symlinks to files with "odd" file extensions. One contrived example:
When opening either the symlink or the actual file, VSCode starts with a Language Mode of C++. But after some time automatically (or after making a small edit to the file), it will revert to a Language Mode of C. Even if I manually change the Language Mode back to C++, it will still revert to C later. These files are C++ source files, so the C++ start is correct. Reverting to C causes incorrect syntax highlighting and false positives for compiler errors. Making a copy of the file to a different place without the odd part at the end of the file causes the Language Mode of the editor to stay on C++. So there is something odd about the extension of the actual file.
I have tried adding the following to my user settings to see if that would make a difference, but while it did get VSCode to recognize both files a C++ files without manual intervention initially, it still ended up reverting back to C at some point:
Changing the state of
C_Cpp.autoAddFileAssociations
did not seem to make any difference. Also, this issue did not occur with the"C_Cpp.intelliSenseEngine": "Tag Parser"
setting (it stayed on C++ Language Mode for both the symlink and the actual file). So it appears to be something with the default IntelliSense engine.Steps to reproduce:
Test.C,1.1^123
, make it a simple "Hello World" like the below:int main() { std::cout << "Hello World" << std::endl; return 0; }
Other Extensions
N/A
Additional context
https://github.com/user-attachments/assets/a9cdac22-96ba-404c-8256-feaf541b54b4