[Triple] Add "swift" as a vendor.

[al45tair]

We want this so we can uniquely identify our fully-static Linux target using a triple (since we wish to make decisions about it in the compiler driver that wouldn't be appropriate for an "unknown" triple).

rdar://123436421

[al45tair]

This is a cherry pick of apple#8256.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[MaskRay]

You can freely use a vendor not listed in Triple.h, e.g. you can do --target=x86_64-swift-linux-gnu today without any extra code.
Actually, some VendorType values are redundant and probably should be there in the first place.
A VendorType member is only needed when it has some special behavior. However, recent Driver improvements try to provide generic mechanisms (e.g. configuration file) to provide customization instead of adding hard-coded logic.

[al45tair]

@MaskRay Yes, however I do need special behaviour in the Swift compiler, which uses the LLVM Triple class, hence I do actually need to add this here.

[al45tair]

(I'm aware of the config file support, and indeed I'm using that to avoid making additional changes to the Clang driver.)

[MaskRay]

Do you have a link to the customization?

[al45tair]

I'll dig out some links to PRs I have open on Swift. But it's probably helpful to explain what I'm up to — I'm trying to get Swift into a state where it's possible to build fully statically linked binaries for Linux, and I'm using musl as part of that, but I'm not using the same software stack that a typical musl distro would use (so I'm using compiler-rt and LLVM libunwind, not libgcc, and I'm using libc++ rather than libstdc++), plus everything is statically linked. For the most part for the Clang side of things, the config file will work (at least for the moment, though in the long term it might be useful to teach the driver the right settings), but Swift has no equivalent to that and needs to make various decisions in its code that wouldn't be appropriate for a normal musl distro.

I don't want to rule out Swift on e.g. Alpine, and I certainly don't want to break Clang for anywhere it works currently on musl-based systems, hence the desire to distinguish the fully-static Swift set-up from some musl-based distro or other.

[al45tair]

An example from one of the PRs I have open against Swift: https://github.com/apple/swift/pull/71844/files#diff-f768ac8c03b01ed7761b76d70eaa046bd6032a4b7559873d13fd46a5033c9e83

(There are others, I think, in various parts of the code.)

[MaskRay]

I'll dig out some links to PRs I have open on Swift. But it's probably helpful to explain what I'm up to — I'm trying to get Swift into a state where it's possible to build fully statically linked binaries for Linux, and I'm using musl as part of that, but I'm not using the same software stack that a typical musl distro would use (so I'm using compiler-rt and LLVM libunwind, not libgcc, and I'm using libc++ rather than libstdc++), plus everything is statically linked. For the most part for the Clang side of things, the config file will work (at least for the moment, though in the long term it might be useful to teach the driver the right settings), but Swift has no equivalent to that and needs to make various decisions in its code that wouldn't be appropriate for a normal musl distro.
I don't want to rule out Swift on e.g. Alpine, and I certainly don't want to break Clang for anywhere it works currently on musl-based systems, hence the desire to distinguish the fully-static Swift set-up from some musl-based distro or other.

Thanks for stating your motivation. It's helpful.

Using compiler-rt / libunwind / libc++ is not that atypical.
Both Gentoo and Chimera Linux provide such setting.
Changing rtlib/unwind/stdlib can be done with a configuration file as your PR demonstrates.

Have you thought about not coupling these decisions with a new vendor?
A normal musl target triple can use static linking as well.

[al45tair]

Changing rtlib/unwind/stdlib can be done with a configuration file as your PR demonstrates.

Not in the Swift compiler it can’t, because Swift doesn’t have config files, which is why the triple change is necessary.

Again, the motivation here is to avoid setting everything up in a way that causes problems for “stock” musl distributions later on.

[al45tair]

@MaskRay Please can you remove your request changes from this PR? You're blocking it unnecessarily at this point.

[al45tair]

Going to merge this in Apple's fork instead.