[PATCH] D131351: [C] Default implicit function pointer conversions diagnostic to be an error

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D131351#3718421 <https://reviews.llvm.org/D131351#3718421>, @mstorsjo wrote:

> I found another case of this warning, which is kinda borderline whether it really is an error not:
>
>   #include <stdlib.h>
>   static _Noreturn void my_exit(void) {
>     exit(42);
>   }
>   __attribute__((noreturn)) void (*handler)(void) = my_exit;
>
> The fix is simple though, just be consistent with `_Noreturn` vs `__attribute__((noreturn))` on both function and function pointer.

Oh wow, that one is neat, weird, and I'm not certain what I think about it yet. `__attribute__((noreturn))` is part of the function type, which is why you're allowed to write it on a function pointer declaration. `_Noreturn` is not part of the function type (nor is `[[noreturn]]` in C2x), so the two functions types do not match and that's why you get the diagnostic. This is the same logic that allows a diagnostic for a case like:

  __attribute__((stdcall)) void func(int a, int b);
  void (*fp)(int, int) = func; // Oops, calling convention mismatch

(on targets where these calling conventions exist and `stdcall` is not the default calling convention).

However, we don't care about the type mismatch when doing a redeclaration or when dropping the attribute, as in:

  __attribute__((noreturn)) void my_exit(void);
  void (*handler)(void) = my_exit; // Silently drops the attribute
  
  _Noreturn void my_exit(void) { // No concerns about the type mismatch on redeclaration because we inherit __attribute__((noreturn))
  }

so maybe we shouldn't worry about it here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131351