Settings: Let's be warning-free by GNOME 43

[amyipdev (Amy Parker)]

Hello there! This is my first post here on GNOME Discourse. I’m Amy, a recent contributor to GNOME Settings. A lot of my work so far has been cleanup and warning resolution; a lot of the projects I’ve worked with in the past compile with -Werror, so I’ve gotten accustomed to trying to clean out errors whenever I see them. I generally think it’s a good practice, as it increases maintainability and provides a little more sense of security in terms of bug count.

GNOME Settings throws tons (recent pipeline yielded 63) of warnings during compile. While these have gone down with time, there’s a lot that are still present. As anyone still using a.out knows, continuing to use deprecated functions is not a good long-term strategy for maintainability. Deprecation is the main source of warnings currently in Settings, mostly from four culprits:

1. NetworkManager. Hand-counting yielded 12 warnings, all of which were from deprecated functions. Most of these appear to be legacy connection (usually removal) functions, but NM provides no replacement indicators, so someone knowledgeable with the panels will have to help work with this.
2. ModemManager. Of course NM’s cousin is going to be involved here as well! There’s this one (enum?), MMMobileEquipmentErrorDeprecated, which as the name indicates is deprecated. I don’t know what needs to be done to fix this - yet another case of leaving no deprecation messages - but it is something that needs to be fixed, as anywhere that enum is currently used a warning (22 by my count) is generated.
3. CUPS/PPD. I can work on this one, and will be shortly, since CUPS thankfully provides proper deprecation messages. However, it is something that does need to be updated. By my count (count("and friends") / 2) there are 21 of these.
4. libupower. This one only has two warnings, but we need a familiar developer to fix them.

There’s also strays like some dead code in color and a cast-to-const in printers, but those four make up almost all of the outstanding warnings. (Wanted to put links, but new-user-limits got in the way)

I think it would be a really great idea - and would set a really great example - to get warning-free soon, potentially as soon as GNOME 43. While it’s certainly not a major thing, it would be something fun to show off GNOME code cleanliness. Maybe we could even get an addition in someone’s minor release notes.

– amyipdev

[cwendling (Colomban Wendling)]

I sounds like a good idea to modernize and improve the code, but I just want to stress out that getting rid of compiler warnings should be made with great care: way too often have I seen junior developers get rid of warnings in a way creating more problems than they were solving. That is because depending on the warning set, the compiler will output warnings that are not entirely trivial to fix properly, and that require proper understanding of the code around. The most harmless of those I can think of of the top of my head is explicit casts hiding a warning that actually showed a small (or seldom bigger) issue in the code (e.g. the code should have used the correct-sized integer type, not merely cast away the warning), but there are way more insidious ones.

Anyhow, the goal is great, but I want to stress out that fixing warnings require to properly understand what they actually mean, and why they appear in the first place instead of just doing the least amount of efforts to shut the compiler up.

I am not suggesting you don’t know what you’re doing by any means (and actually, looking at your message you seem to be very sensible and careful about this), and I’m excited to see more polished code, but I wouldn’t want such an initiative to spread out the wrong way.

[mcatanzaro (Michael Catanzaro)]

Thing is, if they are not 100% suppressed, people will introduce new bugs because they’ll never see other warnings. So this is important to do.