vscode-cpptools icon indicating copy to clipboard operation
vscode-cpptools copied to clipboard

Colorization only loads after changing the name of a file. And remains very buggy after change.

Open fragmential opened this issue 1 year ago • 2 comments

Environment

  • OS and Version: MacOS Sonoma 14.2.1
  • VS Code Version: 1.85.1
  • C/C++ Extension Version: v1.18.5

Bug Summary and Steps to Reproduce

Bug Summary:

When opening any project in VS Code, the syntax highlighting from the extension is missing, the other features of the extension remain working. Some files work as expected, some don't.

After renaming the file to something else, the colors are restored to the correct state. (see screenshot with filename before and after change) Screenshot 2024-01-11 at 11 57 51 Screenshot 2024-01-11 at 12 00 44

However, after changes are made to the file, the colorization does not behave properly, as when changes are made to the file, all colorization to the text after the changes are seemingly broken and does not restore itself with time (see image).

Screenshot 2024-01-11 at 12 03 51

I can't reproduce this second part all the time however, as sometimes after changing filename it does behave properly.

After any amount of file changes or any amount of time, when renaming the file back to its original name, the colorisation will return to its broken state.

I can also find no pattern of which files are affected. When I create a new file and copy paste the exact same code, and quit and reopen VS Code, still only the previously affected file is affected.

Uninstalling and reinstalling the extension did not affect the bug.

Reproduction:

  1. Open any C or C++ file.
  2. The colorisation may not work.

Expected behavior: The colorisation works and remains unaffected by the filename.

Possible fix: Rename the file, quit VS Code, reopen VS Code. rename the file back, and then quit and reopen VS Code again. Now seemingly the file no longer gets affected. I have absolutely no idea what part of this actually solved the issue. After doing this, I can't reliably reproduce the bug anymore.

Configuration and Logs

config:

{
  "configurations": [
    {
      "name": "Mac",
      "includePath": ["${workspaceFolder}/**"],
      "defines": [],
      "macFrameworkPath": [
        "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks"
      ],
      "compilerPath": "/usr/bin/clang",
      "cStandard": "c17",
      "cppStandard": "c++17"
    }
  ],
  "version": 4
}

C/C++ diagnostics:

-------- Diagnostics - 11/01/2024, 12:08:12
Version: 1.18.5
Current Configuration:
{
    "name": "Mac",
    "includePath": [
        "/Users/dante/Documents/Embedded Systems/embeddedSystems/**"
    ],
    "defines": [],
    "macFrameworkPath": [
        "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks"
    ],
    "compilerPath": "/usr/bin/clang",
    "cStandard": "c17",
    "cppStandard": "c++17",
    "compilerPathIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "compilerPathInCppPropertiesJson": "/usr/bin/clang",
    "intelliSenseMode": "macos-clang-arm64",
    "mergeConfigurations": false,
    "browse": {
        "path": [
            "/Users/dante/Documents/Embedded Systems/embeddedSystems/**",
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
cpptools version (native): 1.18.3.0
Translation Unit Mappings:
[ /Users/dante/Documents/Embedded Systems/embeddedSystems/analyser.cpp ]:
    /Users/dante/Documents/Embedded Systems/embeddedSystems/analyser.cpp
Translation Unit Configurations:
[ /Users/dante/Documents/Embedded Systems/embeddedSystems/analyser.cpp ]:
    Process ID: 18521
    Memory Usage: 91 MB
    Compiler Path: /usr/bin/clang
    Includes:
        /usr/local/include
        /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/c++/v1
        /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/include
        /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include
        /Library/Developer/CommandLineTools/usr/include
    Frameworks:
        /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/System/Library/Frameworks
    Standard Version: c++17
    IntelliSense Mode: macos-clang-arm64
    Other Flags:
        --clang
        --clang_version=160000
Total Memory Usage: 91 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 9953

Other Extensions

When I encountered the bug. I had disabled the majority of all my extensions, and there are no enabled extensions left that affect C/C++ files.

Additional context

No response

fragmential avatar Jan 11 '24 11:01 fragmential

Hi @diddy0dante . The behavior you're describing sounds like it may have something to do with VS Code itself, not identifying files as being associated with the C/C++ Extension. If you are able to reproduce this issue again, could you set "C_Cpp.loggingLevel": "Debug" and provide the output of the C/C++ channel (starting before the repro)?

Colengms avatar Feb 09 '24 02:02 Colengms

Thanks for the reply. I have recently not encountered the bug anymore. I will set the logging level in case it ever comes back. I think this issue can probably be closed until I or someone else encounters it again and gets stuck with it.

fragmential avatar Feb 11 '24 02:02 fragmential

Hey @Colengms, this issue might need further attention.

@diddy0dante, you can help us out by closing this issue if the problem no longer exists, or adding more information.

github-actions[bot] avatar Mar 12 '24 11:03 github-actions[bot]