clang-arm intelliSenseMode selected instead of clang-arm64 on Apple Silicon machine

Brief Issue Summary

The configuration provider for C++ extension in VS Code is supposed to automatically detect include paths.

It also should not ignore user-provided paths in the configuration file when failing to auto-find the paths (thought this might not be up to this extension – if so, ignore that).

Expected:

1. Passing CMake Tools as a configuration provider
2. All system include paths are resolved. If not, at least user-provided paths are taken.

Apparent Behavior:

1. Passing CMake Tools as a configuration provider
2. Squiggly include directive for system files show up saying for instance: “cannot open source file iostream”

Configuration file

// File: .vscode/c_cpp_properties.json
{
    "configurations": [
        {
            "name": "Mac",
            "includePath": [
                "/usr/local/include",
                "/Library/Developer/CommandLineTools/usr/include/c++/v1/**",
                "/Library/Developer/CommandLineTools/usr/lib/clang/12.0.0/include/**",
                "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/**",
                "/Library/Developer/CommandLineTools/usr/include/**",
                "${workspaceFolder}/**"
            ],
            "defines": [],
            "macFrameworkPath": [
                "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks"
            ],
            "compilerPath": "/usr/bin/clang",
            "cStandard": "c11",
            "cppStandard": "c++20",
            "intelliSenseMode": "clang-arm64",
            "configurationProvider": "ms-vscode.cmake-tools"
        }
    ],
    "version": 4
}

Platform and Versions

• Operating System: macOS Big Sur on Apple Silicon (M1 chip)
• CMake Version: cmake version 3.19.1
• VSCode Version: 1.51.1
• CMake Tools Extension Version: 1.5.3
• Compiler/Toolchain: Apple Clang 12

[bobbrow]

I believe those are the exact switches we pass to the compiler when doing the query (and also -dD for defines), but the log doesn’t show the right paths being used, so I’m not sure what’s going on there. Until we get full support ready, you may not be able to use the configuration provider and will have to manually set includePath with the system includes that you get from running the compiler query. Just remember to keep the system include paths in the exact order they are reported and also to list them last in the includePath. You can also set compilerPath to the empty string "" to disable the compiler querying temporarily.

I recommend tracking microsoft/vscode-cpptools#6595, but based on our current schedule it may not be ready until cpptools version 1.4 which means you’ll probably have to live with the workaround for a little while.

I was going to close this issue because it looks like CMake Tools is doing the right thing and we just need to wait for cpptools, but I do think it’s passing the wrong IntelliSense mode clang-arm instead of clang-arm64. If it’s alright with you, I’ll repurpose this issue to cover that investigation.

[bobbrow]

@reconndev, just FYI, cpptools doesn’t support the new Apple Silicon processor yet. https://github.com/microsoft/vscode-cpptools/issues/6595

There was a PR to enable the extension to run in emulated mode, but we haven’t released that version yet. Which version of cpptools are you using? Did you patch the code manually to allow it to run on Apple Silicon? If that’s how you got it running, then I suspect there is a problem querying the compiler for the system includes. I don’t see anything wrong from the CMake side here. You definitely don’t want to put system include paths in the includePath variable because gcc/clang are picky about the order of includes due to the way they structure their headers.

The Translation Unit Configurations: at the end shows you what the final include path (including system includes) was resolved to. The fact that your sysroot is not in there points to a problem with the compiler querying logic. For this to be the case though, I expected to see a warning in the Output channel I mentioned earlier.

cc: @Colengms

(The TypeScript callstack points to a problem with a bad character in your c_cpp_properties.json file. We should probably wrap the call to jsonc.parse with a try/catch - that’s another bug for cpptools)