r/cpp • u/c0r3ntin • 5d ago

Clang 23 Release Notes

https://releases.llvm.org/23.1.0/tools/clang/docs/ReleaseNotes.html
108 Upvotes

98% Upvoted

32 comments sorted by

46

u/mapronV 5d ago

This means that code such as

while (({ break; })) {}

is now ill-formed.

Oh no, my disappointment is immeasurable and the whole day is ruined!

On serious note, " template for " support, what is "Iterating expansion statements currently cannot be expanded" ? like expand over range?

5

u/KeepTheFaxMachine 5d ago

I am really curious if there is a use case for such constructs? I can't think of any, but usually that doesn't mean much...

6

u/scrumplesplunge 5d ago

idk about break specifically, but return appearing there via a macro like TRY_OR_RETURN for propagating errors by value seems like something someone would write

2

u/KeepTheFaxMachine 4d ago

Right, that might be a use case, though I'm still not sure if that is a real use case or just a symptom of bad design elsewhere.

2

u/Som1Lse 3d ago

Just to be clear, that still works. The change is that breaks and continues in conditions don't apply to that loop. As the release notes point out

for (;;) {
  while (({ break; true; })) {}
}

is valid, and now breaks out of the for loop, whereas before it broke out of the while loop. This makes Clang more compatible with GCC, which already did this.

6

u/thehutch17 5d ago

What does that code even translate to? Is this a digraph thing or what?

13

u/holyblackcat 5d ago

Non-standard GNU extension, statement expression.

4

u/cristi1990an ++ 5d ago

like expand over range?

Yeah, pretty much it seems. The other flavors work

1

u/mapronV 5d ago

Thanks, I was confused for a bit plus lazy to check different code in compiler explorer.

2

u/SignalDepth6131 4d ago

mapronV, the notes only say this: Clang has partial support for P1306R5. Iterating expansion statements currently cannot be expanded and will result in a diagnostic. Other types of expansion statements work. They do not define "iterating," and they do not say it means expand-over-range. cristi1990an's reading is a reasonable guess, but it is not in the notes.

I'll point out that people still use Boost.Mp11 when they want to walk a type list on today's compilers. That's a workaround, not a stand-in for the missing iterating form.

29

u/Ok_Independence_9841 5d ago

Fascinating to see just how complex and approximate compilation really is. That a compiler can have that many things wrong/broken/missing and still be really good and reliable in practice is pretty terrifying. clang does look to be maturing really well though. The three way C++ compiler arms race has worked well for developers and the for the language, if not for other compiler vendors. I hope it remains balanced and they don't specialize or diverge.

8

u/WeeklyAd9738 5d ago

 I hope it remains balanced and they don't specialize or diverge.

-pedantic flag (and its modern alias -Wpedantic) is your friend.

7

u/Ok_Independence_9841 5d ago

Yes. I have -Wall -Wextra and -Wpedantic on for my projects.
My concern is more that MSVC might try to leverage their advantage in STL compliance by forging ahead with STL additions, while GCC pushes languages updates because they are ahead there. This could lead to GCC standard library never actually catching up (modules cough) while MSVCs lack of certain language features starts to require work arounds. That way we do not want to go.
So far the competition, clang in particular, has meant that all 3 are reasonably close in features for some definition of reasonable. It was not always so.

3

u/mapronV 5d ago

IIRC MS only removes vendor-specific flags lately. Just was upgrading my pet project to compilation with latest VC, had to update bunch of 3rdparty that used MS extensions in headers.

To be fair all 3 major have own problems, MS I'd say really began lagging in core language, hope they catch up. STL part is decent

2

u/azswcowboy 5d ago

> advantage in STL compliance

You think MSVC is ahead on this? I’d be curious why you think so when my take is that especially on later features libstdc++ is ahead.

5

u/STL MSVC STL Dev 4d ago

We were focusing on finishing C++23, and just merged constexpr cmath.

2

u/azswcowboy 3d ago

Just went and checked the status — and wow yes — excellent work on 23! Super cool to see. And MSVC is likely the only real implementor of constexpr math at this point. Still, that looks like basically parity with libstdc++ for 23 and they’ve shipped a lot of 26 features, so for the moment I think they’re still ahead on later features.

2

u/pjmlp 3d ago

Still much better than in the 90's pre C++98, where Java even interpreted (JIT only came into early 2000's, version 1.3), was quickly adopted straight away in 1996 in my university, saving the autocofigure/m4 macros and #ifdef pain, and distractions while teaching courses whose main focus was compilers and distributed computing.

We had one C++ compiler per OS, the vendor one, plus all the other commercial ones that have died during the last two decades.

6

u/gracicot 5d ago

That's a huge amount of bugfix, congrats!

3

u/JVApen Clever is an insult, not a compliment. - T. Winters 4d ago

For the clang-based tooling: http://releases-origin.llvm.org/23.1.0/tools/clang/tools/extra/docs/ReleaseNotes.html

2

u/zerhud 5d ago

Oh no, there is still no constexpr structure binding

1

u/UnusualPace679 5d ago

What do you mean? The page does mention:

Clang now propagates constinit and constexpr in structured bindings with tuple-like initializers.

1

u/zerhud 5d ago

Hm.. but here is “no” for “constexpr structured bindings”

3

u/UnusualPace679 4d ago

Yeah, it should say "partial". Apparently this pull request #214006 aims to fix this.

1

u/LB-- Professional+Hobbyist 5d ago

Extended the -marm64x flag to support compiling to object files. When used in this mode, separate compilation jobs are run for ARM64 and ARM64EC object files, which are then merged into a single file using a new .obj.arm64ec section.

I got this working with a CMake toolchain file, it works quite well for building ARM64X binaries very simply. However, it seems to break try_compile in a subtle way? CMake can't detect if architecture-specific macros are defined anymore - no errors or warnings, just no macros found. I haven't been able to dig into it much, I just manually hacked around it for my use case.

3

u/not_a_novel_account cmake dev 3d ago

I would appreciate it if you opened a bug with whatever you experienced at: https://gitlab.kitware.com/cmake/cmake

At the very least this won't get lost.

1

u/LB-- Professional+Hobbyist 3d ago

I'm struggling to find where exactly to do that? I'm signed in but I can't find any UI elements related to submitting issues or bug reports. I see work items and issue boards but these don't seem to be for outside users to submit bug reports, and I can't figure out how to create any myself. Searching around online, old links go to an /issues URL that doesn't seem to exist anymore. Am I missing something obvious?

3

u/not_a_novel_account cmake dev 3d ago

https://gitlab.kitware.com/cmake/cmake/-/work_items

"New item" in the top right.

If you can't submit for some reason you can just message me the write up or post a gist/pastebin/whatever and I'll forward it along.

2

u/LB-- Professional+Hobbyist 2d ago

Ahh thanks, somehow I completely missed that button. I think I've done it: https://gitlab.kitware.com/cmake/cmake/-/work_items/28063

0

u/---sms--- 4d ago

It hadn't been complex until 2d