This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Dear Maintainer,

your package has not been built successfully in 32. Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. Following the latest policy for such packages [2], your package
will be orphaned if this bug remains in NEW state more than 8 weeks.

A week before the mass branching of Fedora 33 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 31 will be
retired regardless of the status of this bug.

[1] https://fedoraproject.org/wiki/Updates_Policy
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedoraproject.org/wiki/Releases/33/Schedule

Not sure where this is coming from; 5.1.4 was already released and fixes this issue: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1b5f3160ec

swift-lang-5.1.4-0.1.20200131git2194dc2.fc33 and swift-lang-5.2-0.7.20200219git998f2de.fc33 also fails according to https://koji.fedoraproject.org/koji/packageinfo?packageID=27252

This is blocking the Python 3.9 rebuild.

For the build logs with Python 3.9, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01251640-swift-lang/

For all our attempts to build swift-lang with Python 3.9, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/swift-lang/

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/

Let us know here if you have any questions.

Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon.
We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.

I think this is unrelated to Python 3.9 but an issue with something with Clang 10. I'm able to build everything successfully using 31, but neither 32 nor Rawhide. Note that I'm not working on 5.1.4 as it will presumably soon be superseded by 5.2 so that is the version I'm trying to get working.

So as an update, it builds fine in F32, but not in Rawhide; the version of Clang is the same, so not sure what the difference might be that is making the difference.

I think I've tracked it down to Rawhide having CMake 3.17.0-rc1 vs Fedora 32 having 3.16.4. I've had issues with CMake before (and they even made a version to fix one of my reported issues); still tracking down how it's getting triggered.

I tracked the issue down to a change in CMake 3.17, the specific issue is the addition of the 'config' entry here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmNinjaTargetGenerator.cxx#L963. If anyone is interested in my discussions with the Apple folks, that's here: https://forums.swift.org/t/building-libdispatch-on-linux-crashes/34319/5. 

Hopefully this can be worked out at the CMake level; the file that is causing the issue is not patchable insofar as it's generated as part of the build process.

Fixed in current release of CMake