I agree that this would be a good thing to aim for as long as we exclude
deprecation warnings (given Apple's penchant for deprecating large API
surfaces such as OpenGL or the older accessibility APIs we really can't
have the use of deprecated APIs be an error).
-- Kevin
On 11/24/2021 7:44 PM, Michael Strauß wrote:
That's a good idea. In general, warnings should always be treated as errors.
On Thu, Nov 25, 2021 at 2:01 AM Martin Fox <mar...@martinfox.com> wrote:
The Mac glass code generates a lot of compiler warnings. I tried cleaning this
up and discovered that two of the warnings are brand new, courtesy of me. One
of the headers in PR #651 has a typo that I didn’t catch and neither did the
two reviewers. The compiler generated two warnings but they were lost in the
sea.
I turned on warnings-as-errors for the Mac glass code and waded through the
results. There are a couple of minor coding errors in addition to mine which
should be cleaned up (like passing NO to a function that requires a non-null
pointer). There’s also a few deprecated calls across a small handful of files
which have easy replacements and are probably worth fixing.
Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the
older forms (I think this was to rationalize the naming with Swift). These form
the bulk of the warnings and affect multiple files. Not a fan of that sort of
code churn but the alternative is to live with a slew of warnings forever.
Apple is not going to un-deprecate those constants.
You can see the changes I made in my github repository (beldenfox/jfx) in the
branch ‘macwarnings’. There’s multiple commits, the first and biggest catching
most of the easy stuff like constant renaming.
In the short term it might be worth disabling deprecation warnings and turning
on warnings-as-errors. Then at least outright coding errors (like mine!) have a
chance of being caught.
