Hi,
After an update-checkout, trying to re-build the the compiler for Xcode with SKIP_XCODE_VERSION_CHECK=1 ./swift/utils/build-script --xcode --release-debuginfo --debug-swift --skip-build-benchmarks --swift-darwin-supported-archs "$(uname -m)" --sccache --skip-ios --skip-tvos --skip-watchos and clang: **error:** unknown argument: '-fswift-async-fp=always' come up, the problem seems that for Xcode builds it is using the pre-built version that ships with Xcode (using 12.5.1), ninja build seems fine since it uses the one built from source. We have a similar problem before, here [SR-14714] Builds with non-swift/main Clang fail with unknown LLVM argument · Issue #57064 · apple/swift · GitHub but with a different flag.
So my question is if there is a simple way to get around this? Make Xcode builds use the from source built clang or it is better to download and try a beta version of Xcode to fix this? Or maybe another approach?
Thanks in advance!
To me, it seems like a bug that the --xcode build doesn't use the locally built Clang. Different build systems should still be using the same overall compilation commands, otherwise this issue will keep coming up from time to time because of the skew between apple/llvm-project and what is available in the latest Xcode release.
The required version of Xcode is currently 13 beta 4 or newer, according to the information on ci.swift.org and GettingStarted.md.
I think the build-script should only contain that version number, so we don't need to use SKIP_XCODE_VERSION_CHECK=1 for newer versions (e.g. the release candidate).
The only issue is that Xcode build numbers may not be monotonic, for beta and release versions.
Unless the NDK clang is tracking LLVM's main fairly closely, I expect you'll run into problems with async/await support, because Swift is relying on custom async calling conventions implemented in LLVM within the last few months.
Now, this particular change that adds the -fswift-async-fp=always flag is only specifically relevant to Darwin, because the default behavior on all other platforms is good enough. We should go ahead and not pass the flag for non-Darwin platforms.
That doesn't necessarily help @LucianoPAlmeida's Xcode build. We can disable the flag there, and I think only the back-deployed concurrency stuff under development will break, so perhaps that is enough.
The danger here is that these flags may have an effect on code generation, and if the C++ bits of the Swift runtime are built without them, the resulting runtime could be broken.
Unless the NDK clang is tracking LLVM's main fairly closely, I expect you'll run into problems with async/await support
It doesn't track it that closely, as the latest NDK 23 from last month appears to use a clang commit from January. I built the Sept. 2 trunk source snapshot of the Swift toolchain with the upstream clang 12.0.1 on my Android phone, and all the compiler validation suite Concurrency tests passed on Android 11 AArch64 so it hasn't been a problem yet.
We should go ahead and not pass the flag for non-Darwin platforms.
OK, I will submit a pull for that.
The danger here is that these flags may have an effect on code generation, and if the C++ bits of the Swift runtime are built without them, the resulting runtime could be broken.
Good to know. Is the plan to let the Swift-forked clang permanently diverge from upstream clang or get these clang differences upstreamed eventually, as @DaveZ has been monitoring for?
The plan is to get it all upstream. This flag is already upstream (it went there first), but there’s always lag until the next release for a given platform/vendor.
Oh, I see you upstreamed it on Thursday. Looking at your patch, it appears removing that flag from the non-Darwin stdlib build will change it on non-Darwin from never to the default of always, but it had the same behavior before you added the flag, so I guess always should be fine too.
I'll submit the pull in a little bit, thanks for the info.
I built the Sept. 2 trunk source snapshot of the Swift toolchain with the upstream clang 12.0.1 on my Android phone, and all the compiler validation suite Concurrency tests passed on Android 11 AArch64 so it hasn't been a problem yet.
I looked into this a bit more, and while a few C++ files in the stdlib are built with the host clang, ie upstream clang 12.0.1 in the Termux app, most are built with the Swift-forked clang that should have the changes you refer to, so that explains why that problem hasn't hit. My Android CI cross-compiles from linux with the NDK clang instead, so maybe the problem exists there but the Concurrency library is probably not used or exercised much by those Swift packages tested there yet.
Thanks for the response @Douglas_Gregor,
I think for me disabling the flag for the Xcode build locally would be just enough, will not affect the workflow I currently have. But as @typesanitizer mentioned this is a recurrent issue that occurs whenever a new flag is added on clang to support some new swift fix/feature for example [SR-14714] Builds with non-swift/main Clang fail with unknown LLVM argument · Issue #57064 · apple/swift · GitHub, so for that problem maybe the solution would be make the Xcode build use the locally built from source clang the same way ninja builds do today.
I think it would be just fine, but I don't have much understanding about side effects such change would have ... do you think is a viable option?
Hey yall, I filed that jira ticket yesterday while somehow missing this discussion here.
Last night, I ended up deleting all of my previous Xcode versions and downloaded the 13.4 beta and accompanying command line tools to see if that would fix this issue. I started the build again without the skip xcode version check var, but I woke up to a failed build again with the same error messages this morning.
@RyanK@amritpan It is still an issue for all Xcode builds right now, there are more details on @Finagolfin's PR here https://github.com/apple/swift/pull/39368 but we still don't have a fix, and at least as far as I know we don't have a work around it as well ... so Xcode builds are not working right now.
Does someone found a workaround for building it?
Thanks! I've gotten a working build by going back to the 5.4 release with git checkout swift-5.4-DEVELOPMENT-SNAPSHOT-2021-03-19-a && utils/update-checkout --tag swift-5.4-DEVELOPMENT-SNAPSHOT-2021-03-19-a. This works for the meantime
That is fairly old: you should just checkout swift-DEVELOPMENT-SNAPSHOT-2021-09-14-a, which was the last tag before the commit adding this flag was merged.
