mirror of
https://github.com/rust-lang/rust.git
synced 2026-05-04 09:53:04 +03:00
Jonathan Brouwer
416d0bf523
c-variadic: more precise compatibility check in const-eval tracking issue: https://github.com/rust-lang/rust/issues/44930 This came up in the stabilization report discussion https://github.com/rust-lang/rust/pull/155697#discussion_r3139778447. As a reminder, this is what C says (in section 7.16.1.1 of the [C23 standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#page=302). > 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