Time to celebrate C++ Insights' 7th birthday!

As a birthday present, I managed to switch C++ Insights to Clang 20! This enables you to explore more C++23 and C++26 features with C++ Insights.

I hit fewer than usual obstacles. Let me describe what changed.

size_t

For a long time now, when you used size_t or std::size_t the resulting transformation kept the name. It did not expand to the underlying machine-specific date type. To be honest, that was more like a happy accident. Clang 20 came with two changes to libc++

The first https://github.com/llvm/llvm-project/commit/d6832a611a7c4ec36f08b1cfe9af850dad32da2e modularized <cstddef> for better internal structuring, avoiding too much content to be included. This patch was followed by a second one: https://github.com/llvm/llvm-project/commit/5acc4a3dc0e2145d2bfef47f1543bb291c2b866a. This one now made an interesting change.

Previously, libc++ defined std::size_t as

1

using ::size_t _LIBCPP_USING_IF_EXISTS;

As the second patch highlighted, this required including the operating systems <stddef.h>. In the spirit of reducing unnecessary includes the line was changed to:

1

using size_t = decltype(sizeof(int));

This is an easy C++ solution to get the proper data type for size_t. Which is great. Yet, the AST nodes of the two versions look different. Previously, the operating system (macOS in this case) defined in its header:

1

typedef unsigned long size_t;

Well, with the new version, the transformation no longer stops at size_t but expands it all down to unsigned long. This probably should have been the case from the beginning, but I liked that tests and transformations did not change across platforms in this specific case. However, there are other instances where the transformation did yield different output on different platforms, so I accept this one.

Lambdas

I mean, come on, they are everywhere and difficult to get transformed, right? For the past since C++17, the call operator of a lambda is implicitly constexpr. The compiler evaluates at compile-time whether the body of the call operator satisfies all constexpr requirements. I never found a way to acquire the same knowledge as the compiler. Hence, the transformation looks like:

1

inline /*constexpr */ auto operator()() const

The constexpr is in a comment to illustrate the implicitness. Now with Clang 20, the constexpr has dropped occasionally for examples like the above. I haven't fully understood what's going on, but the AST no longer marks that function as constexpr so there is nothing I can do about this.

Support the project

You can support the project by becoming a GitHub Sponsor, or Patreon or, of course, with code contributions.

Andreas