clang should not warn -Wshorten-64-to-32 when it knows shorten is safe

[rockeet]

#include <limits.h>
unsigned int cvt(unsigned long x) {
    [[assume(x <= UINT_MAX)]];
    return x;
}

shorten is safe with [[assume(x <= UINT_MAX)]];.
see https://godbolt.org/z/aoPjxco5r

[tbaederr]

That is static-analysis territory. Clang doesn't do a full flow analysis.

[rockeet]

[[assume(x <= UINT_MAX)]] is an intentional and explicit attribute, and it should be easily handled, so I think this issue should not be essential dup with #105837 which is hard to resolve ---- although these two may be handled in a same stage.

[AaronBallman]

I still see these as duplicate reports but I'm looking at it from the perspective of the compiler. This diagnostic is emitted from the frontend at a time when the only information we have is "this is the sub-expression we're doing semantic analysis for" -- we don't have information about prior expressions and statements unless we perform an analysis to go find that information.

What's more, the explicit attribute still requires control flow analysis. Consider:

void func(auto x) {
  if (something(x)) {
    [[assume(x <= UINT_MAX)]];
  } else {
    [[assume(x > 12 && x < 100)]];
  }
  // Do stuff with x.
}

[Explorer09]

There are cases where we developers don't want to add explicit downcasts to integer types of smaller width.
An explicit downcast would be like saying "I want to discard the upper bits / the upper bits are dont-cares". If I can guarantee that the upper bits would be all zeros (for unsigned integers) or same as sign bit (for signed integers) via the context, implicit downcast should be okay.

The point is to not warn where it can never have undefined behaviors. Warnings that could result in lots of false positives should be turned off by default.