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

[Bob Wilson]

> On Aug 7, 2017, at 1:55 PM, John McCall via swift-dev <swift-dev at swift.org> wrote:
> 
> 
>> 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.

Minor correction: it used to be that way a while back, but more recently, the compiler sources on opensource.apple.com have matched the Xcode releases. For some reason, that page has lagged behind and the latest release posted is from Xcode 8.2.1.

> 
>> 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.
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev