Use libcxx from Darwin SDKs when building LLVM and Swift

[edymtt]

Those are present since Xcode 12.5, so we don't need to copy them
anymore from the toolchain

In this scenario, clean up any existing symlink in incremental builds to
avoid masking or causing errors in the future.

Addresses rdar://102387542

[edymtt]

@swift-ci please test

[edymtt]

@swift-ci please build toolchain

[edymtt]

@swift-ci please test Apple Silicon

[ldionne]

This makes sense to me, but you should make sure that you don’t use -nostdinc++ or -nostdinc when building, since that would disable the default place where clang looks for libc++ headers.

[edymtt]

Windows toolchain job fails with

‘build/artifacts/*’ doesn’t match anything, but ‘*’ does. Perhaps that’s what you mean?

which happens for other PRs as well, so considering this unrelated to this change.

[edymtt]

It seems we are using -nostdinc++ in one place in Swift code, and from the comment in there it seems it is on purpose

https://github.com/apple/swift/blob/17d3065215ece966bd0e0a3a51fdb76f785b654a/stdlib/public/Cxx/CMakeLists.txt#L9

[edymtt]

For macOS test, we are hitting

Failed Tests (1):
  lldb-api :: lang/swift/clangimporter/static_archive/TestSwiftStaticArchiveTwoSwiftmodules.py

This happened for other PRs (e.g. #62121 in https://ci.swift.org/job/swift-PR-macos/4836) but it seems to have clear up in later attempts (e.g. https://ci.swift.org/job/swift-PR-macos/4844/) so retrying it

[edymtt]

@swift-ci please test macOS

[edymtt]

The Apple Silicon bot seems to be hitting issues in finding libc++ headers (which we did not hit in the regular one)

******************* TEST 'Swift(macosx-arm64) :: Interop/SwiftToCxx/class/swift-actor-in-cxx.swift' FAILED ********************
<snip>
/Users/ec2-user/jenkins/workspace/swift-pr-arm64-macos/branch-main/build/buildbot_incremental/swift-macosx-arm64/test-macosx-arm64/Interop/SwiftToCxx/class/Output/swift-actor-in-cxx.swift.tmp/actor.h:29:10: fatal error: 'cstdint' file not found
#include <cstdint>
         ^~~~~~~~~
1 error generated.

[compnerd]

I cannot really comment on the change in practice, but the commit message and the change look like they match. I assume that this was a change to the layout of the SDK? Do we need to be worried about building against old layouts?

[hyp]

@compnerd This change to SDK has shipped since Xcode 12.5. We are assuming you need something >= Xcode 12.5 to build Swift already I believe.

[edymtt]

Realized that the Apple Silicon failure is legit, and it fact it now happens on a regular bot which did not inherit the symlink from a previous run

@hyp kindly provided test changes in #62139 -- on my side I would need to clean up any existing symlinks, since they could become stale (e.g. point to an installation of Xcode that is no longer present) and cause/mask compiler errors.

[edymtt]

@swift-ci please test

[edymtt]

@swift-ci please build toolchain

[edymtt]

@swift-ci please test Apple Silicon

[compnerd]

I'm testing a fix for the Windows toolchain build @edymtt (#62138)

[edymtt]

New changes with the cleanup at 5519977 -- I would suggest to use Hide Whitespace to get a sense of the change, since I had to change indentation

These new runs are expected to fail for macOS, mainly want to be sure I did not regress the other platforms

[compnerd]

Thanks for the comments about the versioning!

[edymtt]

Now that LLVM is using a proper build-script product (#38507), reworked this accordingly in #62159

Leaving this PR around for now in the remote case we need to fall back to build-script-impl logic

[edymtt]

We did not need to go back to the old build-script-impl product, so closing this PR