Enable compiler warnings by default in User Preferences

[brianrho]

Describe the problem

Compiler warnings are inhibited (not displayed) by default in both Arduino 1.x and 2.x -- the Preferences set Compiler Warnings to "None":

arduino-ide/arduino-ide-extension/src/browser/arduino-preferences.ts

Line 113 in 73b6dc4

default: 'None',

This is bad for normal development -- doubly so for a platform dedicated to beginners who will undoubtedly make lots of mistakes, which they will find not only hard to debug, but also hard to report to get help, unless people know to tell them to enable warnings in the IDE first.

I see there is a similar issue raised here about a year ago, that's been stalled: #1792.

To be clear, any argument to raise the warning level to -Wall should be entirely separate, an improvement after the minimum has been met. This issue I'm raising here is that having warnings entirely disabled in an IDE by default is already a bug. It should be "Default" at the very least.

To reproduce

• On any ESP32 platform, using any moderately complex example, write a new function that does something simple like printing some strings, whose prototype indicates it returns something -- but skip the return statement at the end of that function. Say, (untested):

uint32_t print_stuff(uint8_t number)
{
    Serial.printf("Some stuff, %u", number);
}

(Even worse, imagine this function is one among many new functions in the sketch or some library.)

• Call the function anywhere in loop(), you don't even need to use its (non-existent) return value.
• Compile and deploy. The compiler shows no warnings at all about the missing return.

Expected behavior

Since -Wreturn-type is one of GCC's default warnings, one should've seen a warning during compilation, along the lines of:

warning: no return statement in function returning non-void [-Wreturn-type]

This would allow a user a much better chance of spotting issues like this and resolve them early or as soon as problems are observed on running hardware.

Actual Behaviour

There are no warnings. So, as the program runs, one observes strange hard-to-debug crashes from the ESP32, with stack traces that are near useless for identifying the fault. Only after much hair-ripping, does one luckily come across the function with the missing-return and try fixing that.

And even then a "mere" missing-return seems like such an unlikely root cause, that one is likely to initially discount it, especially since there were no warnings from the compiler (one does not know at first that warnings have been disabled).

This is just an example of an issue that would've been resolved much quicker and easier if warnings were enabled.

Arduino IDE version

2.2.1

Operating system

Linux

Operating system version

Ubuntu 22.04

Additional context

I can see the issue is still right there in the latest source, so verifying with the nightly build is unnecessary.

arduino-ide/arduino-ide-extension/src/browser/arduino-preferences.ts

Line 113 in 73b6dc4

default: 'None',

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the latest nightly build
• My report contains all necessary details

[brianrho]

I do not see any downsides to enabling this setting. All the code that used to compile before, will still compile with this setting. All that changes now is that users (including library authors) will be able to see all (default) warnings emitted while compiling said code, and they have a chance to fix them, especially to avoid future yet-to-be-exposed issues.

Any users who don't like the warnings and know what they're doing, can still go disable them, return it to "None" and take their chances.

[per1234]

Closing as duplicate of #1630. I adjusted the title of that issue to increase the scope to a proposal for changing the default value of the preference. I don't see a need for a separate issue for proposing the default at each individual level of the preference.

[brianrho]

" at each individual level of the preference."

Not sure what you mean here, but I'm fine with continuing discussion on the other issue.