Fix kit detection returning 'unknown vendor' when using clang-cl

[Copilot]

This change addresses item #4638

This changes visible behavior

The following changes are proposed:

• Add detectVendorFromBinaryPath() helper to detect vendor from compiler binary path (clang-cl, clang, gcc patterns)
• Update getKitDetect() to use binary path detection as fallback when kit name patterns don't match
• Return vendor info even when version detection fails
• Fix scanDirForClangForMSVCKits() to generate 'Clang-cl' prefixed names for clang-cl.exe kits

The purpose of this change

${buildKitVendor} expanded to __unknown_vendor__ when using clang-cl.exe because vendor detection relied solely on kit names starting with specific patterns ('Clang-cl', 'Clang ', 'GCC '). Manually added kits or auto-scanned kits often had different naming.

Before:

build-win32-__unknown_vendor__0-unknown-Debug

After:

build-win32-ClangCl20-x64-Debug

Other Notes/Information

Vendor detection patterns supported:

• clang-cl, clang-cl-* → ClangCl
• clang, clang-* → Clang
• gcc, gcc-*, *-gcc, *-gcc-* → GCC

Unit tests added for vendor detection from binary paths including versioned compilers and cross-compilers.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Bug] Kit detection returns "unknown vendor" when using clang-cl</issue_title>
<issue_description>### Brief Issue Summary

Download latest clang package from github.
Add clang kit to Vscode
Change Build output to include ${buildKitVendor}
Configure project

Result:
output directory has unknown_vendor

Note:
It works for clang.exe from the same package but not for clang-cl.exe

CMake Tools Diagnostics

{
  "os": "win32",
  "vscodeVersion": "1.107.0",
  "cmtVersion": "1.21.36",
  "configurations": [
    {
      "folder": "d:\\Development\\oiv\\oiv",
      "cmakeVersion": "4.2.1",
      "configured": true,
      "generator": "Ninja",
      "usesPresets": false,
      "compilers": {
        "C": "d:/Applications/clang+llvm-21.1.7-x86_64-pc-windows-msvc/bin/clang-cl.exe",
        "CXX": "d:/Applications/clang+llvm-21.1.7-x86_64-pc-windows-msvc/bin/clang-cl.exe"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": true,
    "activeBuildType": "Debug",
    "buildTypesSeen": [
      "Debug"
    ],
    "requests": [],
    "responses": [],
    "partialMatches": [],
    "targetCount": 71,
    "executablesCount": 1,
    "librariesCount": 38,
    "targets": []
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": true
    }
  ]
}

Debug Log

N/A

Additional Information

No response</issue_description>

<agent_instructions>You are Copilot coding agent acting as a senior maintainer/contributor for the VS Code extension repository microsoft/vscode-cmake-tools.

You are deeply familiar with CMake, CMake Presets, CTest, kit/toolchain selection, VS Code extension APIs, and the architecture of this repo.

Your job is to resolve the assigned GitHub issue in a maintainable way, matching existing patterns and UX.

When approaching the issue, follow these steps exactly:

1. Read and understand the whole issue thread and identify the problem/request before starting work on the solution.
2. If the issue is a regression, look at previous commits and PRs. Note in the PR comments where you think the regression occurred and in what PR/commit.
3. Before generating a solution, see if there is an existing solution pattern elsewhere in the vscode-cmake-tools repo that you can follow. Consider also looking at the docs hosted in the repo as well.
4. Always follow existing structures and conventions for maintainability. Be aware of regression risks.
5. Always add tests covering the changes if it makes sense. Also make sure to update the existing tests to handle the changes if needed.
6. For localization changes, never update any files under the i18n directory. You can assume that the changes you need to happen in those files will by updated later based on the localization changes you made elsewhere in the repo.
7. Once you have come up with a solution to the assigned issue, update the description with the root cause of the issue, the solution to the issue, how the solution addresses the issue, what tests where added/updated and why, and how to manually verify the changes especially focusing on how to test regression risks.
8. Make sure to update the changelog with an explanation of how the solution affects the user experience (not what we changed internally). For improvements and bugs, link the assigned issue. For features, link the PR with the feature changes.

Note: When addressing Intellisense issues, you may need to look at how the CMake Tools extension interfaces with the Cpp Tools extension. The Cpp Tools extension handles C and C++ Intellisense by allowing other extensions to interface with it. You may want to look at the vscode-cpptools repo to understand how the CMake Tools extension interfaces with the Cpp Tools extension. Here is the Cpp Tools extension repo link (vscode-cpptools): https://github.com/microsoft/vscode-cpptools</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes [Bug] Kit detection returns "unknown vendor" when using clang-cl #4638

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[snehara99]

@copilot you linked the wrong issue in the PR and in the changelog. It is issue #4638

[Copilot]

@copilot you linked the wrong issue in the PR and in the changelog. It is issue #4638

Fixed in e714594. Updated the CHANGELOG and PR description to reference the correct issue #4638.

[snehara99]

@copilot could this cause any regressions?

[Copilot]

@copilot could this cause any regressions?

The changes are designed to be additive and backward-compatible:

Low regression risk because:

1. Name-based detection preserved: The original logic that detects vendor from kit names starting with 'GCC ', 'Clang ', or 'Clang-cl' is unchanged (lines 291-296). Binary path detection only activates as a fallback when name patterns don't match.

2. Existing kits unaffected: Kits that already work (those with standard naming patterns) will continue to use name-based detection. The new binary path detection only helps kits that previously returned __unknown_vendor__.

3. Graceful fallback: If binary path detection also fails, the original kit is returned unchanged (line 302-304), matching the previous behavior.

Potential edge cases covered by tests:

• Cross-compilers like arm-linux-gnueabihf-gcc → GCC
• Versioned compilers like clang-14, gcc-11 → correct vendor
• clang-cl checked before clang to avoid false matches
• Unknown compilers return the original kit unchanged

Manual verification recommended:

• Test with existing GCC/Clang/MSVC kits to ensure no behavior change
• Test with clang-cl kits (the original bug)
• Test with custom-named kits