[bla3]

expressive diagnostics was one of clang's early selling points: https://clang.llvm.org/diagnostics.html

Clang was released 2007 and was usable 2009/2010-ish. Rust dev started 2010.

I'm not saying the trend of having good diagnostics was started by clang, but it's a more believable than the claim that it was started by Rust.

--

Rust-the-language is nice, but the Rust community feeling the need to mention Rust on every unrelated thread is a bit of a turn-off for me.

[linkdd]

Template errors with g++ vs clang++ are what made me abandon the gcc toolchain for my dev environment (I still build against both compilers in my CI/CD though).

Rust wasn't even a thing (not as hype and mature) at that time.

Rust is nice, but the hype train is toxic (and that's true for every language/technology).

[thrwaeasddsaf]

GCC also copied clang's excessive diagnostics and I'm seriously thinking of making a fork just to strip them out. I doubt the developers would accept a patch that implements --stfu.

[nindalf]

Every change breaks someone's workflow. But you are the closest I've seen to the person complaining here - https://xkcd.com/1172/

[thrwaeasddsaf]

Yeah. It's funny how back in the day people used to make fun of excessively long compiler errors involving templates.

Now everyone seems to praise the compiler barfing three screenfuls of text and code and explaining the include hierarchy of my project and expanding all the macros and making bogus suggestions because I mistyped a variable name.

It's gotten to the point where locating the actual error message is literally more work than fixing the code. It doesn't help that this interferes with navigation in emacs and trying to jump to next error instead takes you to the next #include line gcc wants you to learn about.

[bla3]

Does -fdiagnostics-plain-output not do what you want?

[thrwaeasddsaf]

    $ cc -fdiagnostics-plain-output c.c
    cc: error: unrecognized command-line option ‘-fdiagnostics-plain-output’

[bla3]

It's new in gcc 11.1