Is thisclang-20 also the LLVM number? (in three places)

-CC=clang-20 ...+CC=clang-${{ matrix.llvm }} ...

Is thisclang-20 also the LLVM number? (in three places)

-CC=clang-20 ...+CC=clang-${{ matrix.llvm }} ...

Included insavannahostrowski#15, which also combines the Linux steps.

savannahostrowski#16 combines two Windows steps.

That will leave us with these Windows jobs:

#          - target: i686-pc-windows-msvc/msvc#            architecture: Win32#            runner: windows-2022          -target:x86_64-pc-windows-msvc/msvcarchitecture:x64runner:windows-2025-vs2026build_flags:""run_tests:true          -target:x86_64-pc-windows-msvc/msvc-free-threadingarchitecture:x64runner:windows-2025-vs2026build_flags:--disable-gilrun_tests:false#          - target: aarch64-pc-windows-msvc/msvc#            architecture: ARM64#            runner: windows-2022

Note Win32 and ARM64 are commented out, and have been since initial commit exactly one year ago! 🎂cb640b6

Only Windows x64 architecture is run. I suggest we delete the commented code, we can re-add it when we're ready.

And after combining two of the three Windows steps into one, we have two remaining:

      -name:Native Windows MSVC (release)if:runner.os == 'Windows' && matrix.architecture != 'ARM64'shell:pwshrun:|          $env:PlatformToolset = "v145"          ./PCbuild/build.bat --tail-call-interp ${{ matrix.build_flags }} -c Release -p ${{ matrix.architecture }}          if ("${{ matrix.run_tests }}" -eq "true") {            ./PCbuild/rt.bat -p ${{ matrix.architecture }} -q --multiprocess 0 --timeout 4500 --verbose2 --verbose3          }# No tests (yet):      -name:Emulated Windows Clang (release)if:runner.os == 'Windows' && matrix.architecture == 'ARM64'shell:pwshrun:|          choco install llvm --allow-downgrade --no-progress --version ${{ matrix.llvm }}.1.0          $env:PlatformToolset = "clangcl"          $env:LLVMToolsVersion = "${{ matrix.llvm }}.1.0"          $env:LLVMInstallDir = "C:\Program Files\LLVM"          ./PCbuild/build.bat --tail-call-interp -p ${{ matrix.architecture }}

I don't think that second one has ever been run? I suggest we delete that too. And when we're ready, we can re-add as needed. And that might be by combining into the first Windows step instead of a standalone one.

The&& matrix.architecture != 'ARM64' guard in this first step is also redundant and can be deleted.

Thanks for the pulls@hugovk! I was initially trying to be somewhat conservative but I'm inclined to remove the unused job and commented out platforms as well. I think it'll be obvious enough if/when we need to add them back in.

savannahostrowski#17 removes the duplicatetarget list, and then I have one more suggestion that builds on top of that.

And let's also backport.

Thanks@savannahostrowski for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

Thanks@savannahostrowski for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

Sorry,@savannahostrowski, I could not cleanly backport this to3.13 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 30cfe6ee23a8974625c9860bc401f60ed75b2dea 3.13

Sorry,@savannahostrowski, I could not cleanly backport this to3.14 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 30cfe6ee23a8974625c9860bc401f60ed75b2dea 3.14

Before mergingthis PR, here's the diff between3.14 andmain:

Anything on the RHS that should not go back to3.14? Can we just copy the currentmain version back?

(And the file doesn't exist on 3.13, no need to backport there.)

GH-144683 is a backport of this pull request to the3.14 branch.

Anything on the RHS that should not go back to3.14? Can we just copy the currentmain version back?

3.14 cannot use VS2026 (PlatformToolSet v145) for a tailcalling build. The necessary changes are only in 3.15 (#139922)

So on 3.14 we can only use clang (or just omit it to save CI).

cc@Fidget-Spinner