[swift-dev] Correspondence between swift-clang and Apple's Clang end user releases

[John McCall]

> On Aug 7, 2017, at 3:47 PM, Oleksii Vilchanskyi via swift-dev <swift-dev at swift.org> wrote:
> Hello,
> 
> I would like to know when a feature
> (https://github.com/apple/swift-clang/commit/14bfc9e99e6e6903b09480a22c153032be77ae4e)
> was introduced in a binary version of Clang shipped by Apple.
> 
> I tried the latest source code version from
> https://opensource.apple.com, which is clang-800.0.42.1, but the feature
> is not there.

I believe that what gets uploaded to that site is the clang that is used to build the latest
macOS release.  So it doesn't get uploads until macOS is actually released, and the upload
is of a slightly different clang anyway from the Xcode release — typically it's a earlier tag of
the same release branch.

> Then I found a public repository, swift-clang. However, even though I
> see that the commit is on 4.0 branch, I have no idea how to tell the
> precise version when the commit was cherry-picked onto the release which
> gets shipped to the end user (which I assume doesn't happen in this repo).

Apple believes strongly in the LLVM/Clang/Swift open-source process.  While the
ultimate, canonical Xcode release branches (i.e. clang-NNN) are indeed held in
Apple-internal repositories, those branches are continually and automatically merged
from the open-source release branches in the github repositories (i.e. swift-X.Y-branch).
When we want to ensure that an open-source LLVM or Clang commit ends up in an Xcode
release, we don't cherry-pick it directly into our internal release branches, we cherry-pick it
into the github repositories and let it get auto-merged.  There are just so many advantages
to doing it this way that, frankly, we would do it even if we were actively hostile to open-source. :)
So the github release branches should always be a reliable point of truth for whether an
LLVM/clang commit will be present in the release.

The clang binary in a toolchain is built from the same source as the clang components of the
swiftc binary in that toolchain.

> I am also feel a bit frustrated due to the lack of correspondence with
> usual Clang, which is currently at 4.0.1 and has browsable tags
> corresponding to releases at https://llvm.org/svn/llvm-project/cfe/tags/.

The swift-4.0-branch is actually ultimately based on the LLVM's project 4.0 branch, although
the numbering is just a coincidence.  This is something we've done for (I think) the last two
releases and plan to continue doing going forward.  Since the Swift branch is usually targeted for
a significantly later release and does require a substantial amount of specific Clang support, we
do cherry-pick a fair amount into our release that LLVM does not cherry-pick into their release.

John.