SwiftPM plugin doesn't work with the latest Visual Studio version

Development Windows
1

We have been happily compiling Swift executables and compiler plugins on Windows before for a while, however the latest Visual Studio update broke our build pipeline.

I've been able to reduce the issue to the minimal reproducible example which I've uploaded on Github. You can test it with the following command:

swift package plugin tmp_plugin_verb

The repo can be found here.

Can someone please help? @compnerd maybe?

2 Likes
2

Happening to me as well :cry:

3

The full error message:

swift package plugin tmp_plugin_verb
error: plugin compilation failed: <PluginCompilationResult(
    succeeded: false,
    commandLine: %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\bin\swiftc.exe -L %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\pm\PluginAPI -lPackagePlugin -sdk %localappdata%\Programs\Swift\Platforms\6.0.3\Windows.platform\Developer\SDKs\Windows.sdk\ -libc MD -I %localappdata%\Programs\Swift\Platforms\6.0.3\Windows.platform\Developer\Library\XCTest-development\usr\lib\swift\windows -I %localappdata%\Programs\Swift\Platforms\6.0.3\Windows.platform\Developer\Library\XCTest-development\usr\lib\swift\windows\x86_64 -L %localappdata%\Programs\Swift\Platforms\6.0.3\Windows.platform\Developer\Library\XCTest-development\usr\lib\swift\windows\x86_64 -I %localappdata%\Programs\Swift\Platforms\6.0.3\Windows.platform\Developer\Library\Testing-development\usr\lib\swift\windows -L %localappdata%\Programs\Swift\Platforms\6.0.3\Windows.platform\Developer\Library\Testing-development\usr\lib\swift\windows\x86_64 -use-ld=lld -g -swift-version 6 -package-description-version 6.0.0 -I %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\pm\PluginAPI -parse-as-library -Xfrontend -serialize-diagnostics-path -Xfrontend P:\projects\tmp\.build\plugins\tmp_plugin\cache\tmp_plugin.dia P:\projects\tmp\plugin\plugin.swift -o P:\projects\tmp\.build\plugins\tmp_plugin\cache\tmp_plugin.exe,
    executable: P:\projects\tmp\.build\plugins\tmp_plugin\cache\tmp_plugin.exe
    diagnostics: P:\projects\tmp\.build\plugins\tmp_plugin\cache\tmp_plugin.dia
    compilerOutput: "error: emit-module command failed with exit code 1 (use -v to see invocation)
%localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\intrin.h:20:10: note: while building module '_Builtin_intrinsics' imported from %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\intrin.h:20:
 18 | /* First include the standard intrinsics. */
 19 | #if defined(__i386__) || defined(__x86_64__)
 20 | #include <x86intrin.h>
    |          `- note: while building module '_Builtin_intrinsics' imported from %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\intrin.h:20:
 21 | #endif
 22 |

<module-includes>:1:10: note: in file included from <module-includes>:1:
 1 | #include ""immintrin.h""
   |          `- note: in file included from <module-includes>:1:
 2 | #include ""x86intrin.h""
 3 | #include ""mm_malloc.h""

%localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include/immintrin.h:26:10: note: in file included from %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include/immintrin.h:26:
 24 | #if !(defined(_MSC_VER) || defined(__SCE__)) || __has_feature(modules) ||      \
 25 |     defined(__SSE__)
 26 | #include <xmmintrin.h>
    |          `- note: in file included from %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include/immintrin.h:26:
 27 | #endif
 28 |

%localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\xmmintrin.h:31:10: note: in file included from %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\xmmintrin.h:31:
  29 |  * a standard library to provide allocation routines. */
  30 | #if __STDC_HOSTED__
  31 | #include <mm_malloc.h>
     |          `- note: in file included from %localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\xmmintrin.h:31:
  32 | #endif
  33 |

%localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\mm_malloc.h:13:10: error: cyclic dependency in module 'ucrt': ucrt -> _Builtin_intrinsics -> ucrt
11 | #define __MM_MALLOC_H
12 |
13 | #include <stdlib.h>
   |          `- error: cyclic dependency in module 'ucrt': ucrt -> _Builtin_intrinsics -> ucrt
14 |
15 | #ifdef _WIN32

<module-includes>:27:10: note: in file included from <module-includes>:27:
25 | #include ""mbstring.h""
26 | #include ""process.h""
27 | #include ""wchar.h""
   |          `- note: in file included from <module-includes>:27:
28 |

C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt/wchar.h:29:10: note: in file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt/wchar.h:29:
 27 | #include <vcruntime_string.h>

 28 | #if !defined(_M_CEE)

 29 | #include <intrin.h>

    |          `- note: in file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt/wchar.h:29:
 30 | #if defined(__clang__) && (defined(_M_ARM64) || defined(_M_ARM64EC))

 31 | #include <arm_neon.h>


<unknown>:0: error: could not build C module 'ucrt'
%localappdata%\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\intrin.h:20:10: error: could not build module '_Builtin_intrinsics'
 18 | /* First include the standard intrinsics. */
 19 | #if defined(__i386__) || defined(__x86_64__)
 20 | #include <x86intrin.h>
    |          `- error: could not build module '_Builtin_intrinsics'
 21 | #endif
 22 |
"
)>
4

This is related to the latest Windows SDK release (10.0.26100.0). Downgrading the SDK would be a reasonable workaround and ultimately a requirement no matter what as the modulemap definitions cannot be updated retroactively. Once we have figured out how to restructure the modules for this change, you will need to switch to the latest snapshots to resolve this.

You should be able to use the existing flags to select the SDK version (-windows-sdk-version ...).

5

Thanks, that's what I was suspecting as well.

Unfortunately, passing this flag to the swift package plugin invocation isn't supported, and appending it to the failed swiftc invocation from the error message produces a weird error:

<unknown>:0: error: missing required module 'ucrt'

What helped is uninstalling the SDK from the machine entirely.

I'm going to file an issue on the swift compiler repo.

6

relevant issue Compilation error when trying to compile a simple plugin with Windows SDK 10.0.26100.0 · Issue #79745 · swiftlang/swift · GitHub

7

CC: @dschaefer2

8

I think you have to roll back to 17.12? I've been busy working on 6.1 (which works fine BTW) so don't have 6.0.3 set up at the moment.

9

I had a workaround locally that seems to partially work. Fabrice and I paired and tweaked it a bit further. The result of that work is something that we are trying to test and get merged into main. I think that this is likely something that we will want to pull into release/6.1 as well. We do not have a way to backport this to the 6.0 train as the files are part of the toolchain distribution and will require a re-roll of the toolchain. Once merged, if you must use the stable release, you should be able to replace the files in the SDK.

2 Likes
10

Ah cool. Thanks @compnerd!

11

Thanks a lot for the quick fix!

12

It should be possible to pass arbitrary compiler arguments like this:

$ swift package -Xbuild-tools-swiftc -blah plugin ...
13

Ah, the reason I didn't see it is that I still had the 10.0.22000 SDK installed. Feels like we could manage those relationships with MSVC versions and Windows SDK versions a bit better.

14

Yeah, that would be great. That requires more buy in from Microsoft as they release the platform SDK.

Currently, we have the -windows-sdk-version option as the escape hatch. Turns out, the GHA images still have the older SDK available.

15

It seems like the problem is specifically compatibility with the Windows SDK version 10.0.26100.0. Our CI was broken on the swift-webdriver repo and I worked around it by setting up the VS dev environment (vcvarsall) to explicitly use 10.0.22621.0:

    - name: Setup Visual Studio Development Environment
      uses: compnerd/gha-setup-vsdevenv
      with:
        winsdk: "10.0.22621.0"