Re: Making _Noreturn a no-op in < Clang 16?

[Paul Eggert]

On 1/19/23 13:30, Sam James wrote:
> Right, I just meant that we don't tend to care about quieting warnings with 
> older compilers,
> and it's not useful from a static analysis perspective here either given that 
> older Clangs can't be trusted.
>
> It is of course useful as an attribute in general. I don't think either of 
> these things are really
> a downside to committing the workaround here. If we get folks who get build 
> failures with extra warnings
> enabled, we can tell them to upgrade their compiler.

But clang 16 isn't out yet, so we can't reasonably tell people to upgrade.

And even if it clang 16 were out, I can't reasonably tell all Emacs 
developers to switch to it right away. Many of them are using Apple's 
compiler and will upgrade whenever. Plain './configure; make' on a 
bleeding-edge Emacs built from Git with Clang 15 would generate 270 
false alarms if we simply did "#define _Noreturn /**/", and I expect 
many Emacs developers would be annoyed by that (or would stop paying 
attention to any correct diagnostics mixed in with the flood of false 
positives).

With that in mind, how about the attached Gnulib patch? (I haven't 
installed it.) The basic idea is to "#define _Noreturn /**/" on buggy 
clangs if a cautious builder compiles with -D_GL_WORK_AROUND_LLVM_BUG_5979.

0001-snippet-_Noreturn-work-around-Clang-_Noreturn-bug.patch
Description: Text Data