Yes, unfortunately Windows PATH is polluted with everything. We remove standalone installation and use Clang bundled with VS (17.0.3).

Simply doing the following will fix your issue:

$env:PATH = ($env:PATH -split ';' | Where-Object { $_ -ne 'C:\Program Files\LLVM\bin' }) -join ';'

As a side note we also remove C:\Strawberry\c\bin from PATH, because it adds tools with broken line ending handling.

I wish the default PATH were clean and things were opt-in instead of polluting it with conflicting binaries.

#8125 strikes again! The run: choco upgrade llvm fix from last time still works.

HI @mgovers ,

we have run the workflow with your repro steps , we made some changes for workflow and works fine . Please look into my repro steps .

strategy:
  matrix:
    compiler: [clang]

  - name: Build
    run: |
      ${{ matrix.compiler }}++ --version
      ${{ matrix.compiler }}++ -std=c++20 -o myprogram.exe ./.github/workflows/myprogram.cpp

Kindly revert back if you still facing the same issue , we're happy to assist.

It appears clang is working fine again on hosted Windows runners. Well done on fixing something in less than 24 hours, trillion dollar corporation!

@kishorekumar-anchala Does the fix apply to Azure DevOps Windows-2022 agents as well? I'm still seeing the following error.

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\yvals_core.h:898:1: error: static assertion failed: error STL1000: Unexpected compiler version, expected Clang 17.0.0 or newer. [clang-diagnostic-error]
_EMIT_STL_ERROR(STL1000, "Unexpected compiler version, expected Clang 17.0.0 or newer.");
^
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\yvals_core.h:519:44: note: expanded from macro '_EMIT_STL_ERROR'
#define _EMIT_STL_ERROR(NUMBER, MESSAGE)   static_assert(false, "error " #NUMBER ": " MESSAGE)
                                           ^             ~~~~~
1 error generated.

Hi @bdenhollander ,

Currently clang version from both win 19 and 22 images is 16.x , The latest version is in development mode and it will come to live by next roll out.

when coming to your issue , the below workflow may solve it . Try to use it and revert back if you face any issue again.

`
name: C++20 with Clang-1

on:
push:
branches:
- llvm

jobs:
build:
runs-on: windows-latest

strategy:
  matrix:
    compiler: [clang]

steps:
  - name: Checkout source code
    uses: actions/checkout@v4

  - name: Setup LLVM
    run: |
      choco install llvm -y
      echo "LLVM_PATH=C:\Program Files\LLVM\bin" >> $GITHUB_ENV
  - name: Build
    run: |
      ${{ matrix.compiler }}++ --version
      ${{ matrix.compiler }}++ -std=c++20 -o myprogram.exe ./.github/workflows/myprogram.cpp
  - name: Run
    run: .\myprogram.exe`

here i create a strategy to cherry pick clang compiler and tried to execute the code .

Hi @bdenhollander ,

Currently clang version from both win 19 and 22 images is 16.x , The latest version is in development mode and it will come to live by next roll out.

The image has 16.x but it also has Clang 17.0.3 from Visual Studio 2022.

Based on @Sainan's comment, I thought a fix had been rolled out but perhaps a job ran on an older image that hadn't been updated by the rolling release.

Maybe I got lucky. Would advise the choco upgrade step to prevent the intermittent breakage every 3 months or so, haha.

Edit: Yeah, I did get lucky on 2 runs and wrongly assumed it was fixed.

Standalone installation of clang/llvm version should be removed from base image. It is duplicating VS installation. If anyone needs it, they can install it with one command.

HI @mgovers ,

we have run the workflow with your repro steps , we made some changes for workflow and works fine . Please look into my repro steps .

strategy:
  matrix:
    compiler: [clang]

  - name: Build
    run: |
      ${{ matrix.compiler }}++ --version
      ${{ matrix.compiler }}++ -std=c++20 -o myprogram.exe ./.github/workflows/myprogram.cpp

Kindly revert back if you still facing the same issue , we're happy to assist.

In https://github.com/PowerGridModel/power-grid-model/actions/runs/9405944097/job/25908253921?pr=633 you can see you still fails.

As @kasper93 mentioned, the issue is likely more fundamental and I expect his PR #10005 to fix the root cause of the issue.

One side effect is that, you might need to Enter-VsDevShell to access all tools. I don't recall if they are added to PATH by default, but this doesn't change the fact that vendoring two different versions of LLVM is only confusing for everyone involved.

Hi @mgovers ,

as @kasper93 mentioned in his PR , we appreciate his investigation and solution , but we request you to follow the below repro step to produce.

Image: windows-2022
Version: 20240603.1.0
Included Software: https://github.com/actions/runner-images/blob/win22/20240603.1/images/windows/Windows2022-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/win22%2F20240603.1

Please find the below work-around

  - name: Workaround C++ clang
    run: |
      clang --version
      choco upgrade llvm
      # $env:PATH = ($env:PATH -split ';' | Where-Object { $_ -ne 'C:\Program Files\LLVM\bin' }) -join ';'
      clang --version

if issue is still persist , please revert us .

Hi @mgovers ,

as @kasper93 mentioned in his PR , we appreciate his investigation and solution , but we request you to follow the below repro step to produce.

Image: windows-2022 Version: 20240603.1.0 Included Software: https://github.com/actions/runner-images/blob/win22/20240603.1/images/windows/Windows2022-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/win22%2F20240603.1

Please find the below work-around

  - name: Workaround C++ clang
    run: |
      clang --version
      choco upgrade llvm
      # $env:PATH = ($env:PATH -split ';' | Where-Object { $_ -ne 'C:\Program Files\LLVM\bin' }) -join ';'
      clang --version

if issue is still persist , please revert us .

Hi @kishorekumar-anchala ,

The choco upgrade llvm command indeed worked and was already implemented based on the comment by @Sainan

#8125 strikes again! The run: choco upgrade llvm fix from last time still works.

The remove from PATH was not necessary, fortunately

Given that the last Visual Studio upgrade broke in the same way, I’d encourage the GitHub team to think about two things:

• Why is nothing doing a CMake build using clang part of your test matrix before a new image is pushed? Adding that back last August when this last broke would have prevented this update from being deployed. What is your policy for introducing regression tests on this project?
• Why was a potentially disruptive major version update pushed on a Friday?

Both of these point to structural problems that significantly reduce my trust in this platform.

Given that the last Visual Studio upgrade broke in the same way

I agree. This was the issue when MSVC STL started requiring Clang 16: #8153

Should we be expecting another disruption when the MSVC STL starts requiring Clang 18?

@mgovers the new version of LLVM 18 has been rolled out in the latest image deployment.Hope your issue resolves.Thank you.

@mgovers the new version of LLVM 18 has been rolled out in the latest image deployment.Hope your issue resolves.Thank you.

Thanks for resolving. Does this mean that the solution proposed in #10005 will not be implemented? That means, like @davidchisnall and @remyjette mentioned, this issue will be encountered in the future as well.

The permanent fix will probably still be adding a run: choco upgrade llvm step to your workflows. That worked last time, and it worked this time again.