I see this problem all the time if the Swift symlink to the clang headers isn't set up right. Is there a symlink usr\lib\swift\clang that points at the clang headers you noted? If not, it will not find them.

@buttaface I believe that’s not the case on Windows. And it works after I add the symlink manually.

cc @compnerd if we can teach the installer to set up the symlink?

This is a SwiftPM side issue, not a swiftc issue. The fact that this builds correctly with CMake is proof of that.

Building it locally, the problematic part of the repo for me is: https://github.com/apple/swift-atomics/blob/main/Sources/_AtomicsShims/include/_AtomicsShims.h#L63-L65. Changing the order of inclusion, I'm not a fan of - the MSVC headers should be preferred for Windows.

MSVC stdatomics.h doesn't support C so far. It’s even missing in VS 2019.

The Clang header will fall back using #include_next if system header is available, but the MSVC one cannot be used at this point.

This is a SwiftPM side issue, not a swiftc issue.

I was talking about the toolchain, not SwiftPM or compiler. /usr/lib/swift/clang symlink is set up on both Linux and macOS, I don’t think Windows should make a difference here.

No, the clang header will not fallback to MSVC: https://github.com/apple/llvm-project/blob/next/clang/lib/Headers/stdatomic.h#L20-L22.

I would say we should work out why it builds with CMake and not SPM and make SPM behave similar here.

I'm surprised it works with CMake: I can't build anything that calls libc with the Swift compiler if that clang symlink is not there on linux or Android. @stevapple, does compiling the equivalent hello world to this simple file for Windows, ie import CRT or whatever, work if you remove that clang symlink?

import Glibc
print("Hey world")

On linux with this file, I get this error after removing the clang symlink that the toolchain comes with:

> ./swift-5.6.2-RELEASE-ubuntu20.04/usr/bin/swiftc hello.swift
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "SwiftGlibc.h"
         ^
/home/foo/swift-5.6.2-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/SwiftGlibc.h:45:10: note: in file included from /home/foo/swift-5.6.2-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/SwiftGlibc.h:45:
#include <limits.h>
         ^
/usr/include/limits.h:124:16: error: 'limits.h' file not found
# include_next <limits.h>
               ^
<unknown>:0: error: could not build C module 'SwiftGlibc'
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "LibcOverlayShims.h"
         ^
/home/foo/swift-5.6.2-RELEASE-ubuntu20.04/usr/lib/swift/shims/LibcOverlayShims.h:31:10: note: in file included from /home/foo/swift-5.6.2-RELEASE-ubuntu20.04/usr/lib/swift/shims/LibcOverlayShims.h:31:
#include <semaphore.h>
         ^
/usr/include/semaphore.h:22:10: note: in file included from /usr/include/semaphore.h:22:
#include <sys/types.h>
         ^

I would say we should work out why it builds with CMake and not SPM and make SPM behave similar here.

I don’t think it can build with CMake based on an VS 2019 installation. There’s no stdatomics.h provided by MSVC.

SwiftPM can build it successfully with VS 2022 toolset — as long as the symlink is set up. I believe this is the correct behavior, identical to other platforms.

For anyone running Swift 5.7 or older, set TOOLCHAIN_ROOT=C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain and run mklink /D %TOOLCHAIN_ROOT%\usr\lib\swift\clang ..\clang\<clang_version> with an elevated (Administrator) command prompt to work around the problem. Hopefully we can solve this by Swift 5.7.1.