Docs: add an entry about compiler warnings

[mcspr]

per #8421 and #8475
after checking HW, suggest to check SW as well at least by enabling compiler warnings
(and also note of the IDE weirdest defaults causing issues we expected to stay solved)

[d-a-v]

This was missing.

[earlephilhower]

Don't we always generate a warning/error on this case, even with None? If not, I think we can fix it instead of documenting it, by changing the platform.txt options...

Arduino/platform.txt

Line 25 in 15e7d35

compiler.warning_flags.none=-w -Werror=return-type

[mcspr]

only 3 out of 4 options produce error:

Arduino/platform.txt

Lines 24 to 28 in 15e7d35

	compiler.warning_flags=-w -Werror=return-type
	compiler.warning_flags.none=-w -Werror=return-type
	compiler.warning_flags.default=-Werror=return-type
	compiler.warning_flags.more=-Wall -Werror=return-type
	compiler.warning_flags.all=-Wall -Wextra -Werror=return-type

'None' never does, -w overrides any -W flags since they apply all at once and not like 'disable all warnings but still enable this one', order does not matter. Removing -w from 'None' kind of defeats the purpose of the option, and there is 'Default' for that.

We do still need to mention the warnings, which even in 'Default' will give some useful advice. Specifically with C++, shouldn't we mention that it is undefined behaviour when trying to code like that?

btw low-level routines that really do not return may still be coded like this

int func() {
  __builtin_unreachable();
}

[earlephilhower]

Argh, you are correct. Even trying to explicitly enable a warning like -w -Wreturn-type -Werror=return-type doesn't work.

It seems the only way to make this automatically catch is to not use -w and specifically list all ~100 -Wno-XXX in an @option file. While doable, that's more involved than I have time for this AM...