I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.

GCC has gotten better indeed, but it's still in a different league than Clang. I still get into situations where I can't make heads-or-tails of what GCC is saying to me, which can usually be easily solved by switching to Clang.

One problem here is that GCC emits certain warnings as part of the optimizer, which results in many false positives that are essentially impossible for the lay programmer to understand. For example, jump threading might duplicate some code path and propagate constants in it, and then warn about an uninitialized variable / out of range access / etc in that code-path, even though it does not exist in that form in the original program.

Funny enough, this is exactly the kind of situation where other people cry "why did the compiler not warn me about basing optimizations on UB".

I don't do C++ anymore but I will forever remember the Vtable hell "messages" when doing OOP and doing a slight unintuitive mistake about destructor or constructor. Is this still a thing in clang?

Ok, that's kinda true I suppose; I remember that GCC's error messages have indeed gotten better after a major version release.

Also, when you say structured, do you mean errors over LSP, or do you mean more structure in the formatting when reporting in CLI?

GCC returns pretty nice, colored and structured error messages in CLI for quite some time.

I meant in cli a bit like rust arrows logs

clang doesn't output asm

I'm not sure what you mean? You can use `-S`