Revert "Switch to using clang as linker on darwin"

[artemcm]

Reverts #1111

[artemcm]

@keith we are seeing failures in CI with:

ld: file not found: /Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-main/build/buildbot_incremental/toolchain-macosx-x86_64/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_macosx.a\nclang-13: error: linker command failed with exit code 1 (use -v to see invocation)\nninja: build stopped: subcommand failed.\n'

Most likely because we removed the logic in this PR to add -force_load for the libArcLite the driver locates:
https://github.com/apple/swift-driver/pull/1111/files#diff-d44ec7a906797a39be2e42ecb334167ae217537ad09a726d1f905c4ba9130200L169

Could you please take a look?

[artemcm]

e.g. https://ci.swift.org/job/swift-PR-macos/3098/console

[artemcm]

@swift-ci please test

[artemcm]

@DougGregor also pointed out that the issue is due to special logic in clang for this:
https://github.com/apple/llvm-project/blob/next/clang/lib/Driver/ToolChains/Darwin.cpp#L1296
Uses getXcodeDeveloperPath:
https://github.com/apple/llvm-project/blob/next/clang/lib/Driver/ToolChains/Darwin.cpp#L1266

Which isn't doing the right thing to find Xcode. Instead, it should be using:

xcrun -toolchain default -f clang

[artemcm]

So we can either re-add the removed logic for handling arclite back to this driver, or investigate fixing up what Clang driver is doing possibly incorrectly here.

[glessard]

Thanks!

[DougGregor]

The Swift Driver does something a bit more robust than Clang, by checking if the lib/arc actually exists and, if not, fallback back to asking xcrun where the default toolchain is. See https://github.com/apple/swift-driver/blob/60ed7665e3845175dc44c6acf06c4b7b31ddaf55/Sources/SwiftDriver/Jobs/DarwinToolchain%2BLinkerSupport.swift#L18-L48

[DougGregor]

I have a Clang fix that should work: swiftlang/llvm-project#5007

[DougGregor]

I have a PR to reinstate this in #1143