Treat compiler warnings as errors

[PhilMiller]

We should guard against integrating code that introduces new warnings. There are few enough existing warnings that it's worth just fixing them in the process.

Changes

• Build ngen C++ with -Werror
• Build ngen C with -Werror
• Fix the few warnings that appear

Notes

• It's rather important that we're using fixed versions of the underlying toolchain, so that reported warnings aren't a moving target except at update time.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Target Environment support

• Ubuntu Linux 20.04 / gcc on Github CI
• macOS 12 with AppleClang 14 on Github CI

[PhilMiller]

This'll need updates from NOAA-OWP/evapotranspiration#35 and NOAA-OWP/topmodel#47

[PhilMiller]

PET update in PR #785

[PhilMiller]

Topmodel update in that PR too

[PhilMiller]

Looks like there's another round of changes to Topmodel and CFE that'll be necessary to get this through.

[PhilMiller]

My mistake in finding it earlier was apparently in not building with -O1 which does a bit more control and data flow analysis while compiling.

[program--]

May want to wait for other reviewers before merging so everyone is fully aware of the change, but looks good to me!

[aaraney]

This looks good to me too!

[hellkite500]

I'm inclined to pick a core set of tests which we would like to run on latest, perhaps without -Werror, just to help keep an eye on upgrade paths and what is/isn't working on newer tool chains. We can setup an explicit workflow for these. I don't think it is worth running all the various tests, but maybe just the core unit tests as early indicators.

[PhilMiller]

I'm inclined to pick a core set of tests which we would like to run on latest, perhaps without -Werror, just to help keep an eye on upgrade paths and what is/isn't working on newer tool chains. We can setup an explicit workflow for these. I don't think it is worth running all the various tests, but maybe just the core unit tests as early indicators.

I'd be open to adding something like that. I was actually planning to open a follow-on PR trial the switch to Ubuntu 22.04, knowing that it will fail everything right now.

[hellkite500]

Let's open an issue for tracking a latest build CI workflow for a subset of tests, and we can work off that and get this merged. We should probably also check our documentation on supported tool chains and make sure it is consistent. Another issue we may want to open is a plan for CI upgrades.