LLVM tools are not up to date in windows-latest image

[mgovers]

Description

The latest Windows Server 2022 image with Visual Studio build tools

** Visual Studio 2022 Developer PowerShell v17.10.1
** Copyright (c) 2022 Microsoft Corporation

contain Clang CL version 16.0.6, but Clang CL version >=17.0.0 is expected for that build tool set.

Likely related to #9990

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

20240603.1.0

example of failing build: https://github.com/PowerGridModel/power-grid-model/actions/runs/9381448994/job/25830720214#step:6:51

Is it regression?

yes,

latest passing image version: 20240514.3.0

example of passing build: https://github.com/PowerGridModel/power-grid-model/actions/runs/9380566997/job/25827885168#step:6:51

Expected behavior

• Clang 17.0.3 is found (according to https://learn.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-build-tools?view=vs-2022 )
• Build does not fail on STL static_assert checks.

Actual behavior

• Clang 16.0.6 found

-- The C compiler identification is Clang 16.0.6 with MSVC-like command-line
-- The CXX compiler identification is Clang 16.0.6 with MSVC-like command-line

• Build fails on STL static_assert that checks that the Clang version >= 17.0.0

In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\concepts:8:
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.
_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)
                                           ^             ~~~~~

Repro steps

• Create GitHub Action with windows-latest
• Create simple C++-20 program that uses modern STL features:

#include <concepts>

namespace {
struct C{};

template <typename T> concept is_c = std::same_as<T, C>;

static_assert<is_c<C>>;
}  // namespace

int main() {
  C c;
  return 0;
}

• compile with clang-cl
• build fails

[kasper93]

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.

[Sainan]

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

[kishorekumar-anchala]

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.

[Sainan]

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

[bdenhollander]

@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.

[kishorekumar-anchala]

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 .

[bdenhollander]

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.

[Sainan]

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.

[kasper93]

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.

[mgovers]

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.

[kasper93]

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.

[kishorekumar-anchala]

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 .

[mgovers]

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

[davidchisnall]

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.

[remyjette]

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?

[RaviAkshintala]

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

[mgovers]

@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.

[Sainan]

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.