[lvh]

Depends on how you look at it. It's that particular old version of GCC in base because of licensing, yes -- but that old version is now effectively obsolete, so there's a technical reason (originally forced from licensing) to move away from it.

That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_. Clang showed up with colorized error messages and ASCII art arrows and it felt like magic. So, sure, licensing alone would have been a fine reason for base to do what it did, but I don't think it's fair to characterize it as _just_ licensing. GCC has made huge improvements since then, but those are only visible in ports (which has always had and continues to have modern GCC). Which I guess you could argue makes it a licensing issue? :-)

[JdeBP]

I've recently found something to dislike about the coloured error messages.

The default colour is restored after the newline, rather than before it.

* https://github.com/llvm-mirror/clang/blob/6803cc1958b56e0bd5...

I have recently set DECSCNM on in my terminal(s), which inverts everything, effectively swapping the foreground and background colours. The clang error messages now come out with unsightly large streaks of extraneous colour, as freshly erased lines caused by scrolling fill with the colour that clang has not yet turned off. clang was always doing this. But when it's the background colour it's more visible.

It would be such a simple fix, that's actually in line with code elsewhere in the same class. I wonder how many years it will take to get it changed.

[clarry]

> That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_.

I disagree; I think clang set a trend and now GCC's error message are worse than they used to be. In the recent days I've seriously considered patching them out because I'm getting really tired of the wall of text of useless suggestions, macro expansion, etc. that hides the actual error. 99% of the time I just need to see which line my error originates from (before any macro expansion) and I can follow the chain manually in the remaining 1% of cases.

What's happening now is that I have a line with an error, and I get 50 lines of trash output among which the actual error is buried. And trying to jump to the error in my editor has me jump through headers, #include rows, and other garbage, sometimes missing the original error line entirely!

It's ridiculous. The suggestions are also largely either wrong or so obvious that they have only negative value. It's just clutter. Same goes for the ascii art arrows. Just clutter, making it harder to see relevant things.

I can see these messages being helpful for a total newbie who's still acquainting themselves with the standard library and figuring out the basics of the language, but for me (writing C daily for a living, and as a hobby for the past 15+ years) it's just getting in the way.

[dman]

Perhaps users should be given a mechanism for configuring the error printing :)

[Avamander]

I can't help but be reminded of https://xkcd.com/1172/

[JdeBP]

It's a pity that you weren't instead reminded of -fno-color-diagnostics, -fno-caret-diagnostics, and -fno-diagnostics-show-note-include-stack. You could have told clarry about them. (-:

[loeg]

IMO, still very much a licensing issue. Modern GPL3 GCC versions produce superior debuginfo as compared with Clang, in 2020, and the error messages and optimizations are currently competitive between the two. The ancient GPL2 GCC4.2.1 (C) compiled much faster than the modern Clang (C++), but I don't know if that still holds true for newer versions of GCC.

I have heard that the LLD (LLVM linker) is much faster than either ld.bfd or ld.gold.

[guenthert]

In which way terrible? Error messages for C++ were at times unhelpful, but I can't remember being dissatisfied with those for C. Outside the Desktop environment, is there much C++ code in the FreeBSD system?

[JdeBP]

devd is C++, and it is not alone. Unfortunately, the dynamically-linkable C++ runtime library is in the wrong place, and not in the same place as the C runtime library, so things like devd have to be statically linked.

But the clang switch was not motivated by its C++ error messages, to my knowledge.

[lvh]

I was making a general comment about clang vs gcc: the push to clang was not exclusive to FreeBSD.