This year in LLVM

What FUD, clang 15 can't certainly not compile my C++ projects written with C++20 modules, and cppreference clearly shows where it is.

The language support might be nearly done but libc++ definitely does not have full C++20 support. For example, ranges, a HUGE feature in C++20, are disabled by default in libc++ (as of version 15, the latest stable release). As another example for a feature I want, std::source_location isn't implemented in libc++ even though it's existed in GCC/libstdc++ for many years now. In this example Clang has had the language support for implementing std::source_location for a while, but it hasn't been merged into libc++ for various reasons (last I checked there was a diff on phabricator that implemented it but there was some debate about the ABI that was being introduced, or something of that nature).

I don't think it's necessarily FUD, many C++ users don't understand the difference between core language features and standard library features. And even when you do understand the difference, with many features (e.g. std::source_location) you can't actually use the feature if libc++ doesn't have it, so the fact that clang itself supports the language feature is a moot point and irrelevant to end users.

I saw another comment explaining how to use libstdc++ with clang. Sure you can do this, but who actually wants to compile their code this way? Especially since it means you need to upgrade your compiler and standard library separately, on different release cadences. For most people this is way too much headache, they'd rather just not use the new features and wait until they're in libc++. You can also compile llvm with custom options to enable experimental features that aren't fully developed (like ranges), but who really wants to do this? Building a custom compiler/libc++ is a huge headache and the features are disabled by default for a reason anyway.

Just to be clear I love LLVM/Clang/libc++ and am huge advocates of them. But there's nothing wrong with pointing out flaws and where there are gaps compared to other implementations.

> This was a single paragraph in a large blog post, why the heck would I be including a detailed analysis of how I reached that conclusion? On one out of dozens of compile-time regressions I investigated? Something I do all the time, and am likely an expert on?

Yes, when you make a questionable claim and you do not provide any evidence or whatsoever on how you reached to that conclusion, you should be ready to be challenged. Especially given the fact that this is a _technical_ blog targeted to people with technical expertise.

You also take the occasion in the article to subtly confuse the uneducated readers by saying

> In particular, the large regression on the right is due to enabling C++17 by default.

as it is some sort of an universal truth that all C++ code bases will risk if they switch to C++17, which I will counterpoint later in my comment with a real-world multi-million LoC C++ project that includes virtually every C++ header in existence (*).

You sort of try to support that claim by saying that bigger sized STL implementation from C++17 is the culprit

> The close to two times slowdown in 7zip O0 builds comes down to STL headers becoming 2-3 times as large in C++17.

and at which point you really got me puzzling because I've worked on C++14 codebases which made the transition to C++17, and some even to C++20, and I never recall discussions taking place because of the build time regression as big as implied by the article. This wouldn't go unnoticed on multi-million LoC projects in a real-world.

But you also continue with a snarky comment such as

> While this is sad, and I had to edit out some choice words on the C++ standardization committee (I hear that this gets even worse in C++20), at least this does not affect non-clang compilers (e.g. Rust) and C code.

You don't provide any constructive criticism nor have I seen you opening the bug for further investigation. All those things create a bad impression and it doesn't seem that your comments are coming from a good place either. It reads as a very biased PoV which is sort of a problem given that you're professionally involved with the work on LLVM, clang and Rust, and along the way you're being paid by RedHat for that type of work.

(*) I've cloned https://github.com/mysql/mysql-server. Whole codebase is roughly around 3M lines of C and C++ code (among other types of source code). I did not do a very scientific experiment because initial results weren't matching what the article has shown but I've ran the RelWithDebInfo builds against {clang, gcc} x {C++14, C++17} and I've repeated that experiment with two different versions of gcc and clang. TL;DR neither clang or gcc build variant do not show a "regression" larger than ~5% in wall-clock time.

1a8a111d8f855a31d0aeffc8f02309b2b82dd410 was an actual point in time when MySQL transitioned from C++14 to C++17, and this commit was used as a base for C++17 builds. 1a8a111d8f855a31d0aeffc8f02309b2b82dd410~1 was used for C++14 builds. No ccache was involved or whatsoever. Everything was dockerized.

Build with gcc-7.3.1: 6m33s (C++14) vs 6m55s (C++17)

Build with clang-5.0.2 3m52s (C++14) vs 3m58s (C++17)

Build with gcc-9.3.1 5m6s (C++14) vs 5m22s (C++17)

Build with clang-8.0.0 4m39s (C++14) vs 4m49s (C++17)