[PATCH] D124258: [C89/C2x] Change the behavior of implicit int diagnostics

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Precommit CI failures are down to just clang-format related ones. However, as with the implicit function declaration diagnostic, I expect there to be a long tail of failing tests which aren't caught by me locally or by the precommit CI bots. My plan is to track the bots closely whenever I do land this and fix up breakage as it's noticed. Hopefully it won't be too disruptive, but changing diagnostic behavior for ancient extensions like this turns out to be almost impossible to get a fully clean commit from in one go. (If someone wants to run this patch through their own configuration and report back failures before I land, I'm happy to make those fixes now.)



================
Comment at: clang/docs/ReleaseNotes.rst:168-169
+  ``-Wno-error=implicit-int``, or disabled entirely with ``-Wno-implicit-int``.
+  As of C2x, support for implicit int has been removed, and the warning options
+  will have no effect. Specifying ``-Wimplicit-int`` in C89 mode will now issue
+  warnings instead of being a noop.
----------------
rsmith wrote:
> aaron.ballman wrote:
> > rsmith wrote:
> > > Is there some fundamental reason why implicit int is harder to support in C2x (as there was for implicit function declarations, because unprototyped functions are gone), or are we merely taking the opportunity to do this because C2x is new? I find the former more easily defensible than the latter, but I suppose the fact that we removed implicit function declarations means that C2x is the first really properly breaking change that C has had, so maybe now is the time regardless.
> > Purely the latter -- C2x didn't make anything harder here. However, I'd like to position C23 as "not your grandfather's C" in Clang by strengthening diagnostics, especially ones related to safety or security vulnerabilities. Basically, I think it's time to cut ties with as many dangerous things that have been excised from C as possible. I think implicit int fits that goal in the same way that implicit function decls do (namely, the implicit choice can be wrong and you get surprising silent breakage at runtime if you're lucky).
> > 
> > (FWIW, I'm also hoping to get these sort of changes lumped into Clang 15 so that the pain of upgrading is more localized to just one release rather than strung out over several.)
> OK. I wonder our stricter interpretation of the rules in C23 onwards is something we should be calling out in our documentation as policy?
I'd be okay if we did that -- though, to be honest, we might want to review more of our developer policies regarding standards conformance in general, not just features removed from the language but kept as an extension. For example, I've been pretty sad about our inattention to documenting implementation-defined behaviors in Clang. "The source is our documentation" is cute for a while, but it does our users a disservice just the same, so it'd be nice to start setting policy that new implementation-defined stuff needs to be explicitly documented properly. I'm guessing we may find other such policy tweaks we'd like to make.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124258/new/

https://reviews.llvm.org/D124258