> On Aug 7, 2017, at 1:55 PM, John McCall via swift-dev <firstname.lastname@example.org>
>> On Aug 7, 2017, at 3:47 PM, Oleksii Vilchanskyi via swift-dev
>> <email@example.com> wrote:
>> I would like to know when a feature
>> 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
>> 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
> ultimate, canonical Xcode release branches (i.e. clang-NNN) are indeed held in
> Apple-internal repositories, those branches are continually and automatically
> from the open-source release branches in the github repositories (i.e.
> When we want to ensure that an open-source LLVM or Clang commit ends up in an
> 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.
> swift-dev mailing list
swift-dev mailing list