How can Autoconf help with the transition to stricter compilation defaults?

[Aaron Ballman via cfe-commits]

On Mon, Nov 14, 2022 at 1:14 PM Paul Eggert <eggert at cs.ucla.edu> wrote:
>
> On 2022-11-14 04:41, Aaron Ballman wrote:
> > it's generally a problem when autoconf relies on invalid
> > language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And Clang therefore must be
> careful about how it diagnoses invalid constructs. Clang shouldn't
> willy-nilly change the way it reports invalid constructs, as that can
> break Autoconf.
>
> > issues of security
> > like statically known instances of UB
>
> It's fine to report those; I'm not saying don't report them. All I'm
> saying is that Clang should be careful about *how* it reports them.
>
> At the very least if there are going to be changes in this area, the
> Clang developers should notify Autoconf (and presumably other)
> downstream users of the changes, and provide a supported way to get the
> old behavior for reporting, and give downstream time to adapt.

Definitely agreed about the communication aspects! I mentioned this upthread:

FWIW, we're working on improving communication
about potentially disruptive changes to Clang, so you might want to
consider either subscribing to the clang-vendors code review group at
https://reviews.llvm.org/project/members/113/ (if you want to be
involved in code review before things land) or the Announcements
discourse channel at https://discourse.llvm.org/c/announce/ (if you
want to be notified after something lands but before Clang ships).

One other thing we've done recently is starting to call out
potentially disruptive changes in the release notes as well:
https://clang.llvm.org/docs/ReleaseNotes.html#potentially-breaking-changes
-- but this is more for notifying folks after a release goes out, so
one of the other approaches is more proactive if the goal is to alert
Clang developers to serious deployment problems before we ship.

~Aaron