NFD/NFC file paths not supported by C/C++ Extension

[AlexandraKemperMS]

Environment

• OS and Version: MacBook Air, MacOS version is 13.4.1
• VS Code Version: VSCode version is 1.85.0.
• C/C++ Extension Version: The extension version is 1.18.5.

Bug Summary and Steps to Reproduce

Bug Summary: From twitter, I was made aware of an issue with NFC/NFD in a file path. Here is the twitter conversation.

Due to NFC/NFD issue, VSCode C/C++ extension bugs when file path contains NFD. This bug occurs regardless of the file content. When the file path contain NFD, "enhanced colorization" and "error squiggles" don't work. Also "rename symbol" don't work properly.
For example, "/Users/[username]/Desktop/Ё.c" causes this bug. When I open a workspace, this bug occurs if ${workspaceFolder} contains NFD and doesn't occur even if ${relativeFile} contains any NFD.

Configuration and Logs

Not Available - has been requested.

Other Extensions

No response

Additional context

No response

[daidai411411]

Hello. Thank you for creating this github issue. I found this bug and tweeted it.

This bug doesn't occur in "/Users/daidai/Desktop/Е.c" but occurs in "/Users/daidai/Desktop/Ё.c".("daidai" is my username)

• enhanced colorization
  

• error squiggles
  

Here is a result of "C/C++: Log Diagnostics" while opening "/Users/daidai/Desktop/Е.c" and "/Users/daidai/Desktop/Ё.c".

Logs from running "C/C++: Log Diagnostics" from the VS Code command palette

-------- Diagnostics - 2024/1/30 16:24:14
Version: 1.18.5
Current Configuration:
{
    "name": "Mac",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [],
    "macFrameworkPath": [
        "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks"
    ],
    "compilerPath": "/usr/bin/clang",
    "cStandard": "c17",
    "cppStandard": "c++17",
    "intelliSenseMode": "macos-clang-arm64",
    "compilerPathInCppPropertiesJson": "/usr/bin/clang",
    "intelliSenseModeIsExplicit": false,
    "cStandardIsExplicit": false,
    "cppStandardIsExplicit": false,
    "mergeConfigurations": false,
    "compilerPathIsExplicit": false,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
cpptools version (native): 1.18.3.0
Translation Unit Mappings:
[ /Users/daidai/Desktop/Е.c ]:
    /Users/daidai/Desktop/Е.c
[ /Users/daidai/Desktop/Ё.c ]:
    /Users/daidai/Desktop/Ё.c
Translation Unit Configurations:
[ /Users/daidai/Desktop/Е.c ]:
    Process ID: 8855
    Memory Usage: 19 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.2.sdk/usr/include
        /Library/Developer/CommandLineTools/usr/include
    Frameworks:
        /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/System/Library/Frameworks
    Standard Version: c17
    IntelliSense Mode: macos-clang-arm64
    Other Flags:
        --clang
        --clang_version=160000
[ /Users/daidai/Desktop/Ё.c ]:
    Process ID: 8867
    Memory Usage: 19 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.2.sdk/usr/include
        /Library/Developer/CommandLineTools/usr/include
    Frameworks:
        /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/System/Library/Frameworks
    Standard Version: c17
    IntelliSense Mode: macos-clang-arm64
    Other Flags:
        --clang
        --clang_version=160000
Total Memory Usage: 38 MB

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

I updated my MacOS version yesterday, but the bug still exists.

Current Environment

• OS and Version: MacOS(Sonoma 14.3)
• VS Code Version: 1.85.2 (Universal)
• C/C++ Extension Version: 1.18.5

In addition, I found that the problem about "rename symbol" is the same as #6194. This problem is not related to NFC/NFD.

[Colengms]

I'm not able to repro this issue as described. My understanding is that Windows file system uses NFC, and while the underlying file system on macOS is NFD, macOS returns paths normalized to NFC in the shell and from high level API calls. So, macOS is effectively NFC, above those APIs.

I do see a scenario that appears to be a VS Code bug. It's possible, within VS Code, to rename a file by entering an NFD sequence. (i.e. on macOS, type e followed by enabling the Hex Input Keyboard and typing 0301). This will cause VS Code to get confused about the name of the file, as it will continue to consider the open file as containing the NFD content in the name, despite the file in the filesystem now always being reflect as NFC (such as surfaces in fileChanged notifications, despite being NFD internally). Reloading the window addresses the issue, as the NFC version of the filename is correctly used by VS Code from that point on.

If someone can reproduce an issues that is not explained by the above, could you set "C_Cpp.loggingLevel": "Debug" and provide the output of the C/C++ output channel leading up to the repro? That should indicate precisely which encoding is being used for each file URI provided to us by VS Code, for each call it makes into the extension. I suspect what's happening is that VS Code is providing inconsistent URI's (like the scenario above), which sometimes contain NFC and sometimes NFD. If so, we'll need to move this over to the VS Code repo.

[github-actions]

This issue has been closed because it needs more information and has not had recent activity.