Don't normalize *-unknown-windows-coff as *-unknown-windows-msvc

[MaxDesiatov]

This fixes the inability to use x86_64-unknown-windows-coff and i686-unknown-windows-coff triples with Embedded Swift.

Steps to reproduce:

1. Install latest development snapshot off main, e.g. swift-DEVELOPMENT-SNAPSHOT-2024-03-01-a-osx.
2. Try to build with swiftc -target i686-unknown-windows-coff -enable-experimental-feature Embedded -wmo -c test.swift

Expected result:

Code compiles successfully or an actionable diagnostic message is produced.

Actual result:

<unknown>:0: error: could not find module 'Swift' for target 'i686-unknown-windows-msvc'

[MaxDesiatov]

@swift-ci test

[al45tair]

What would x86_64-unknown-windows-coff be used for with Embedded Swift? Or, put another way, why do we want this?

[MaxDesiatov]

This would allow us to cross-compile to Windows from platforms other than Windows without requiring MSVC toolchain to be installed.

[al45tair]

Interesting. I'm not sure what the license agreement looks like for the separate Windows SDK download, but at least historically I would have been inclined to use the -mingw triple for cross compilation, not least because it supplies headers and import libraries that (in theory at least) are not subject to onerous license restrictions.

I'm not sure that -msvc as an environment in a triple necessarily means that you're using Microsoft's compiler either; even if you are using Visual Studio, Microsoft actually does supply a copy of clang these days (albeit with a back-end based on their compiler). Environments generally relate to the execution environment, not the toolchain (so, e.g. -cygwin implies the availability of the Cygwin DLL and associated POSIX-like runtime; likewise -mingw implies the availability of the Mingw runtime components). I would have expected -msvc perhaps to generate code that links with Microsoft's C runtime. Maybe we should support -coff as well, with the expectation that we don't do that, but I don't know what C runtime it would then be using, if any.

I'd be interested to know what @compnerd thinks about this.

(I'm relaxed about the change itself; it just raises some questions.)

[MaxDesiatov]

but at least historically I would have been inclined to use the -mingw triple for cross compilation, not least because it supplies headers and import libraries that (in theory at least) are not subject to onerous license restrictions.

Parts of MinGW are licensed as GPL. I'm not interested in MinGW per se, only the approach it takes for cross-compilation to Windows.

I'm not sure that -msvc as an environment in a triple necessarily means that you're using Microsoft's compiler either;

This may be correct, but I don't think that justifies the current normalization approach where it defaults to -msvc when no environment is specified.

[al45tair]

This may be correct, but I don't think that justifies the current normalization approach where it defaults to -msvc when no environment is specified.

Maybe. Maybe we should have a -ucrt environment (where use the Universal CRT), and maybe that should be the default. Maybe -coff as a triple should mean that you don't have a C runtime underneath you at all (that's certainly a reasonable thing for Swift to do, at least on Windows, even if we don't support it right now).