swift hello.swift
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "AssertionReporting.h"
^
C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\shims/AssertionReporting.h:16:10: note: in file included from C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\shims/AssertionReporting.h:16:
#include "SwiftStdint.h"
^
C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\shims/SwiftStdint.h:28:10: error: 'stdint.h' file not found
#include <stdint.h>
^
<unknown>:0: error: could not build C module 'SwiftShims'
Swift version:
swift --version
compnerd.org Swift version 5.7.1 (swift-5.7.1-RELEASE)
Target: x86_64-unknown-windows-msvc
It looks like I have one Visual Studio installed in c:\Program Files and one in c:\Program Files (x86). Not sure if one of these two is alias of another.
This is a known limitation of the Swift distribution at the moment. In the case that you have more than one Visual Studio installation, make sure that you are running from the "x64 Developer Command Prompt" associated with the Visual Studio installation that you want to use. Otherwise, it cannot determine which version to use and will choose the none option - which ensures that the user doesn't get surprised with a random selection.
@adam-fowler What is the Visual Studio Code extension for Swift doing in this regard on Windows? I would guess that mutiple Visual Studio installations would bring the same problem, as a call through the "x64 Developer Command Prompt" does not seem possible from within the extension? So for the Visual Studio Code extension it should maybe be documented (for now) that on Windows multiple installations of Visual Studio should be avoided.
You’re right. Extensions can only take the environment from the main code.exe process, which makes Visual Studio toolchain really awkward to use in spite that it’s a “1st party” stuff. In most cases (unless you call code from a developer environment with no running instance), that’s the system default environment, so none would be chosen by default.
I have proposed somewhere (in a SwiftPM issue I guess?) that we’d better integrate Visual Studio installation knowledge into SwiftPM or Swift Driver, and that’s achievable through the vswhere tool. This should make VS detection and selection easier.
Then it is likely that the deployment did not work. If you updated the Visual Studio installation after installing Swift, you will need to repair the installation (you should be able to do that from the "Add or Remove Programs" dialog). Otherwise, could you please provide the install log? You should be able to get that by uninstalling Swift and re-installing it and passing /lv*x install.log to installer.exe.
The VS Code swift extension runs swift in the same manner as if it was run from a command prompt. If you installation doesn't from the command prompt it won't work from the extension either.
I'm not sure it is the job of the extension to document install issues. These should possibly be in the Windows install section of swift.org. @compnerd what do you think about adding details about these kind of limitations there.