c-variadic: more precise compatibility check in const-eval

[folkertdev]

tracking issue: #44930

This came up in the stabilization report discussion #155697 (comment).

As a reminder, this is what C says (in section 7.16.1.1 of the C23 standard.

If type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:

• both types are pointers to qualified or unqualified versions of compatible types;
• one type is compatible with a signed integer type, the other type is compatible with the
  corresponding unsigned integer type, and the value is representable in both types;
• one type is pointer to qualified or unqualified void and the other is a pointer to a qualified or
  unqualified character type;
• or, the type of the next argument is nullptr_t and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type

I think the last rule is not relevant for us, we don't really have an equivalent of nullptr_t as far as I know.

r? RalfJung
cc @tgross35

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[rustbot]

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

[folkertdev]

is there some way to check whether a lossless conversion between integer types is possible in the const-eval API that I'm missing?

View changes since the review

[folkertdev]

Given that the changes here are all in const-eval, what (if anything) should be tested in Miri?

View changes since the review