[WIP] Implement WindowsToolchain

[stevapple]

Implemented the Windows-specific toolchain.

[stevapple]

CC @compnerd , I hope to get SPM fully usable on Windows through swift-driver.

[compnerd]

Yes, it will definitely needs arguments for that. At the very least, you need to ensure that the ucrt link matches the stdlib.

[stevapple]

I’m working on the linker part, and now I’m troubled by the following two question:

• Can we use things like link.exe and lib.exe in Cygwin and MingW? That is, is link.exe and lib.exe available to everyone using Swift for Windows?
• Do we also have llvm-lib.exe and lldb-link.exe in Cygwin and MingW toolchains?(we don’t need this)

It’s fairly easy to configure the MSVC linkers and their LLVM drop-in substitutes (I think it can be done today), but what about not using msvc here?

[stevapple]

Another question that I think only @compnerd is capable of answering... Are we going to include clangLibrary (Currently only clangHeaders are included) in Windows Toolchain? If the answer is “yes”, then things will be much easier because we don’t need to search for clang libraries in the whole system.

The dedicated place for it is %TOOLCHAIN_ROOT%/usr/lib/clang/11.0.0/lib/windows, and %TOOLCHAIN_ROOT%/usr/lib/clang/11.0.0 should be symlinked into %TOOLCHAIN_ROOT%/usr/lib/swift/clang.

[compnerd]

The MinGW path should not use the WindowsToolchain but rather the GNUToolchain much Like the model in clang. MinGW is substantially different in ABI that you cannot mix and match the behavior. In fact there's a large number of other things that won't work - like linking because MinGW would require auto link extract that the Windows path does not use as the MINGW doesn't support linker directives. The other thing is that binutils isn't supported by swift because of issues with relocation handling. In general, MinGW isn't ready yet, and would require a lot more than just tweaking the driver.

No, there's no reason to include clangrt, that isn't used on windows.

[stevapple]

clang_rt is required for sanitizer support.

    // Check that we're one of the known supported targets for sanitizers.
    if !(targetTriple.isWindows || targetTriple.isDarwin || targetTriple.os == .linux)

I’m seeing this line of code. It should mean that we are going to provide sanitizer support on Windows?

[stevapple]

Finally gets a solution for sanitizer support. I’m going to filter out any sanitizer other than ASAN. This means if anyone builds his copy with clang_rt, he’ll be able to use ASAN. Other sanitizers will be blocked even if their libraries exist.

What do you think? @compnerd @owenv

[owenv]

Thanks for updating this! It looks pretty good to me, but I'm not very familiar with Windows so I wasn't able to review it thoroughly.

It would be really great if we could include some basic tests alongside this change as well, at least for the platform-specific linking. I think a lot of the windows-related integration tests from the main Swift repo will continue to fail until MSVC runtime handling is added, I haven't looked into how complicated that is. Maybe a couple cases could be added to testLinking in SwiftDriverTests.swift that use the windows target?

[stevapple]

It would be really great if we could include some basic tests alongside this change as well, at least for the platform-specific linking. I think a lot of the windows-related integration tests from the main Swift repo will continue to fail until MSVC runtime handling is added, I haven't looked into how complicated that is. Maybe a couple cases could be added to testLinking in SwiftDriverTests.swift that use the windows target?

Of course I will. However, there is still an unimplemented function (see the only unresolved review😂) which should be implemented before implementing tests.

[stevapple]

Shall we use MD or MT as default for Windows? @compnerd

[compnerd]

I don't think that we should have a default for the value. It must match the value for the runtime that you are building against. I suppose that one possibility is to query the SDKSettings.plist for the correct value like I have done in swift-package-manager. But, really, I think that we should have the user specify the correct value.

[stevapple]

I‘m thinking it necessary. It’s one of our goals to allow user run swiftc without any additional options, which means we should be able to infer every parameter we need from the context.

We can have multiple ways to infer though. plist is one of them, but maybe we also need a hard-coded default.

[compnerd]

If you are adamant that you must have a default, then you must serialize the compile options into the Swift.swiftmodule and then deserialize it to find the default at runtime. Otherwise, whatever default you choose is the wrong one - my runtime will always be the inverse of whatever the default is, and therefore you have just built a binary that will arbitrarily crash.

[stevapple]

I‘d like to know if SDKSettings.plist is built alongside with Windows SDK. If it is (which means every copy of Windows SDK contains SDKSettings.plist), we won’t need an extra default. That would be great and simple.

[compnerd]

It is not, it is only something that is built on my builds of the toolchain; anyone building the toolchain manually will have to deal with that themselves.

[shahmishal]

The Swift project moved the default branch to main and deleted master branch, so GitHub automatically closed the PR. Please re-create the pull request with main branch.

More detail about the branch update - https://forums.swift.org/t/updating-branch-names/40412