These have been moved to subdirectories, and the deleted files were just aliases. The public ones will be removed in a future breaking change.
PiperOrigin-RevId: 691136301
Similar to set_alias for singular submessages, we augment hpb with the ability to add already-allocated messages via the generated function add_alias for repeated messages.
PiperOrigin-RevId: 683269532
As of C23, `va_start` no longer requires a second argument, and ignores it when provided. So, the parameter named `unused` is now...unused.
PiperOrigin-RevId: 683183750
In C23, `false` is now of type `bool`, not `int`. This turned a couple places where `false` was returned instead of `NULL` into errors.
The workaround in upb for Windows's broken NAN macro causes an error in Clang under C23, `cannot compile this static initializer yet`, I believe because `0.0 / 0.0` is not valid in constant-evaluation. This seems like it's probably a legitimate result of C23 standardizing constexpr, although it _could_ be a clang bug. In any case, refine the workaround a bit, to avoid this problem.
I've also reverted the kUpb_FltInfinity/kUpb_Infinity back to their former definitions, as INFINITY wasn't broken by the windows header, only NAN.
PiperOrigin-RevId: 683152452
ListFields uses a slightly different codepath from HasField (both are
implemented in generated_message_reflection.cc), and it would be valuable to
add a test case for ListFields in addition to HasFields when reflection API are
tested.
ListFields is used, for example, in Python textproto serialization as a way to
iterate a message.
ListField behaves slightly differently for normal messages vs. MapEntry
messages. In a map, MapEntry essentially have "explicit presence" and empty
fields are considered present.
PiperOrigin-RevId: 682504379