-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.C files being associated with C instead of C++ in 0.28.2 #5618
Comments
I thought I reproed it one time, but now I'm unable to repro it. The code that deals with this is at https://github.com/microsoft/vscode-cpptools/blob/master/Extension/src/LanguageServer/extension.ts#L567 . I'm seeing ".C" files having the "cpp" languageId due to your settings.json. Are your settings User, Remote, Workspace, or Workspace Folder settings? Is the autoAddFileAssociations setting set to "true"? |
Okay, I reproed it a couple more times. Not sure yet what is triggering it and what fixes it. Looks like a bug/regression in cpptools is causing it to switch to C mode in certain cases. |
And then it stopped reproing again (before I could figure out a cause). Let me know if you figure out a good way to repro it consistently. |
Oh, it stopped reproing because the file got added to the files.associations, but there's a bug in that the 1st time it's incorrectly launched with the C association still until it's restarted. |
Okay, I got the non-temp repro when using "*.C": "cpp" in my files.associations. |
It appears the bug is that we don't send the files.associations change to cpptools. Reload Window after a files.association change should fix it. Let us know if it doesn't. Should be easy to fix. |
Fix for #5618 Scenario 1: Manually change files.associations. Bug: We weren't sending files.associations along with the settings change. Scenario 2: Open a .C file. Bug: The language associations need to be changed before sending the didOpen.
The fix is available with https://github.com/microsoft/vscode-cpptools/releases/tag/0.29.0-insiders . |
Type: LanguageService
Describe the bug
I previously reported an issue in 0.26.1 where .C files were not being treated as C++ files, despite the file associations in my workspace. #4632
This problem seemed to be resolved up through 0.27.1, and now starting in 0.28.0, I'm consistently seeing this problem again in my workspace. Reverting back to version 0.27.1 fixes the problem after a reload, then updating the extension back to any 0.28 version causes the issue to appear again. The workspace is a single project/folder, and is relatively large. Unfortunately the source code is proprietary, so I cannot share the project here.
I am unable to reproduce this behavior using the small project that I posted on the original issue, but this is consistently happening on the proprietary project that I am working on. I will continue to see if I can reproduce this in a smaller scale project that I can share.
Per the C/C++ Log Diagnostics posted below, the extension is using the c11 standard for .C files instead of the c++11 standard, so the C++ standard library paths are not present in the include paths.
Steps to reproduce
Expected behavior
The .C files should be treated as C++ files and use the c++11 standard per the files.associations setting in the workspace.
Logs
C/C++ Log Diagnostics
Note that I've had to redact the real file and directory names for confidentiality reasons, but the file extensions are the same.
c_cpp_properties.json
settings.json
Debug output
Note that I've had to redact the real file and directory names for confidentiality reasons.
Screenshots
Additional context
The text was updated successfully, but these errors were encountered: