[dathinab]

> No, developers don't read compiler error messages, unless absolutely necessary.

This depends fully on the ~language~ compiler.

Some compilers create extremely long verbose but useless messages, other create use-full messages most times only as long as necessary with nice formatting making it easy to skip over the parts you don't care about.

Like e.g. I always read error messages when programming rust, sure I fix a error at a time so I don't read all error messages at once, but I do go through them step by step.

[Arnavion]

With Rust specifically, but also with many languages in general, it's important to read the errors from top-to-bottom because the errors become more and more absurd as they go down.

For example, if there's an error in a macro that was meant to emit a trait impl, the first error will tell you about the error in the macro, and then the fifty errors after that will be fifty different and increasingly confusing ways of telling you that the type doesn't impl the trait.

If you don't start at the top and fix one error at a time you'll just end up chasing and being confused by red herrings.

[estebank]

This is a real thing that rustc does, but we do try to put effort into silencing errors that are caused by earlier ones. If this happens often to you, I would kindly ask for bug reports because I would love to avoid this from happening.

[citrin_ru]

Clang (and modern GCC) warning are quite helpful, but they are ignored because by default they don't break a build (and only a small fraction of C/C++ projects use -Werror). If ignored they may cause problems later when an app will be used. Or may not cause any problems at all - that the case for subpar code in general - it is more likely, but not guaranteed to break.

[PaulDavisThe1st]

-Werror can be hang up development at times, which is why we don't use it with Ardour. Sometimes, it can take a while to understand why some obscure message from the compiler is actually relevant and actionable, and that's not always the main focus while working on features or fixing a specific bug.

However, we do have a policy of expecting that all compiler errors (except those in in-tree 3rd party libs) should be fixed. We take a very negative view of any commits that create new compiler warnings. Essentially, we prefer to have a development culture that treats warnings as errors rather than have the compiler enforce warnings as errors.

When building Ardour, we this as a minimum:

'-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter'

but prefer to use this:

'-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-Wcast-align', '-Wextra', '-Wwrite-strings', '-Wunsafe-loop-optimizations', '-Wlogical-op', '-Wnon-virtual-dtor', '-Woverloaded-virtual', '-fstrict-overflow'

[surajrmal]

For small teams that may work, but at some point, you need to protect yourself from tragedy of the commons. This is especially true during growth periods in the team or periods with significant churn. Culture can very easily shift and having something other than humans involved in ensuring good habits are held is worthwhile.