[clang] [C] Warn on uninitialized const objects (PR #137166)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> arch/arm64/include/asm/barrier.h:164:59: note: expanded from macro '__smp_load_acquire'
>   164 |         union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u;   \
>       |                                                                  ^

Whhhhaaaa? `__unqual_scalar_typeof(*p)` seems to result in a `const`-qualified type. I'm surprised something named `unqual` would do that. Can you confirm I'm getting that correct?

This one:
```
In file included from net/ipv4/ip_fragment.c:42:
include/net/ip.h:478:14: warning: default initialization of an object of type 'typeof (rt->dst.expires)' (aka 'const unsigned long') leaves the object uninitialized and is incompatible with C++ [-Wdefault-const-init-unsafe]
  478 |                 if (mtu && time_before(jiffies, rt->dst.expires))
      |                            ^
include/linux/jiffies.h:138:26: note: expanded from macro 'time_before' 
  138 | #define time_before(a,b)        time_after(b,a)
      |                                 ^
include/linux/jiffies.h:128:3: note: expanded from macro 'time_after'
  128 |         (typecheck(unsigned long, a) && \
      |          ^
include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck'
   11 |         typeof(x) __dummy2; \
      |                   ^
2 warnings generated.
```
is unfortunate. The diagnostic is expected, but I can see why you'd want to silence it. Does adding `= {};` to the declarations for the dummy variable work for you?

> I also see another instance from [a recent change in the crypto code](https://git.kernel.org/linus/db873be6f0549597f92c72986b1939643a7f9a75):

That looks like a correct diagnostic to me, but I admit the code is dense enough I may be missing something. Is there a reason why `addr` should not be initialized? Or is this relying on initialization through other means like `memcpy` into the field because the containing object is non-const?

https://github.com/llvm/llvm-project/pull/137166