Overview of C++ language support in Apple Clang
developer.apple.com
Overview of C++ language support in Apple Clang
1–10 of 50 posts
Re: Overview of C++ language support in Apple Clang
#2When did they start calling it Apple Clang? It was Apple LLVM Compiler for the longest time.
Re: Overview of C++ language support in Apple Clang
#3When did they start calling it Apple Clang? It was Apple LLVM Compiler for the longest time.
As far back as 2007 it was called clang. I'm not sure if it was called clang internally before that. See the seventh slide in the linked presentation.
https://web.archive.org/web/20190403123249/http://llvm.org/d...
Re: Overview of C++ language support in Apple Clang
#4No std::format? Or am I just not searching for the right thing?
Re: Overview of C++ language support in Apple Clang
#5This just lists what they do support, not what they leave out compared to the free alternatives. Here's a better chart -- look at all that red in the Apple clang column: https://en.cppreference.com/w/cpp/compiler_support
I don't understand why they deviate so much from mainstream clang. I think they'd be better off being closer to the trunk. TBH I don't really understand why they have their own tree at all.
Re: Overview of C++ language support in Apple Clang
#6This just lists what they do support, not what they leave out compared to the free alternatives. Here's a better chart -- look at all that red in the Apple clang column: https://en.cppreference.com/w/cpp/compiler_support I don't understand why they deviate so much from mainstream clang. I think they'd be better off being closer to the trunk. TBH I don't really understand why they have their own tree at all.
FWIW, I don't know how much they actually "deviate" (and in fact I do think they have a bunch of likely-needless changes) but they definitely lag a bit what they ship, so the core issue is just that they are behind a version or two, so the differences are almost entirely just "the stuff introduced in clang/libc++ 15/16+" with maybe one or two backports. If it makes you feel any better, the Android NDK copy of clang isn't far off of upstream clang and yet they also often are shipping a slightly older version... it just doesn't warrant its own column as they expose the underlying clang version number, while Apple does this really really annoying thing where the version number of clang is hacked to report a version number based on the Xcode release cycle (so the moral equivalent would be if Android NDK r25c modified clang 16 to report version 25... they don't do that, so they don't really need to be treated as their own compiler ever.)
Re: Overview of C++ language support in Apple Clang
#7When did they start calling it Apple Clang? It was Apple LLVM Compiler for the longest time.
As far back as 2007 it was called clang . I'm not sure if it was called clang internally before that. See the seventh slide in the linked presentation. https://web.archive.org/web/20190403123249/http://llvm.org/d...
Apple has publicly referred to the compiler that they ship with Xcode as the "Apple LLVM Compiler", even though the command line tool was still "clang". E.g., `clang --version` might have reported "Apple LLVM version 7.0.0 (clang-700.1.76)" instead of what it says now, "Apple clang version 14.0.3" on my system.
MacPorts suggests that the --version string changed in Xcode 11 with macOS 10.14 Mojave, but I don't know if the Clang name was reflected in the Xcode GUI at that point. https://trac.macports.org/wiki/XcodeVersionInfo
Re: Overview of C++ language support in Apple Clang
#8Neat! I kept pestering them about how to figure this stuff out and hopefully they got enough people doing it that they finally made a page for it.
Re: Overview of C++ language support in Apple Clang
#9The parallel versioning scheme of apple clang is truly annoying, as it often interferes with feature detection macros
Re: Overview of C++ language support in Apple Clang
#10This just lists what they do support, not what they leave out compared to the free alternatives. Here's a better chart -- look at all that red in the Apple clang column: https://en.cppreference.com/w/cpp/compiler_support I don't understand why they deviate so much from mainstream clang. I think they'd be better off being closer to the trunk. TBH I don't really understand why they have their own tree at all.
They have definitely in the past added features that they later released as part of product launches and then upstreamed, e.g. ARM64 backend or more recently -fbounds-checks (which I think will be in the new Xcode?) Other things I don't think they ever tried to upstream e.g. I think watchOS bitcode might have been special. In the end it's basically the same reason anyone maintains a fork or a set of patches; better integration and prioritization of the things you need for your products and more control over risk, etc.
It would always be nice to slim the differences and get new releases faster though, of course.