The flag is still set, but the runtime doesn't need to check it, instead it uses
the bit set on the message. It also streamlines some of the serialization since
we aren't checking the bit at some of the lower levels.
PiperOrigin-RevId: 725208757
The original intention was to reduce register pressure but we don't have as
much pressure anymore with the new calling convention.
The `bts` instruction has a very high latency, so using other instructions is
actually faster even if more code to run.
PiperOrigin-RevId: 725208340
Resolves the following comiler error, encountered with some client code:
`/usr/x86_64-pc-linux-gnu/include/google/protobuf/message_lite.h:1202:7:
error: ambiguous overload for 'operator<' (operand types are
'const google::protobuf::internal::MessageCreator::Tag' and 'int')
1202 | if (ABSL_PREDICT_FALSE(kMustBeFunc || as_tag < 0)) {
| ^~~~~~~~~~~~~~~~~~`
Closes#19537
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19537 from heirecka:explicitly-convert-an-enum-to-an-int b88571903c
PiperOrigin-RevId: 724740203
These are not for general consumption. They are specifically for projects which have an agreement with protobuf on directly accessing upb. Any other usage is unsupported and may be broken at anytime without warning.
PiperOrigin-RevId: 724391383
Currently upb will only tolerate parsing a message set extension if it's encoded
in the bespoke message set format. If it's encoded as a normal submessage it'll
be relegated to the unknown field set.
As not all encoders are message set aware, tolerating both forms when decoding
will improve compatability.
PiperOrigin-RevId: 724363865
Building with clang produce the following error:
text_format.h:55:1: warning: attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration [-Wignored-attributes]
The warning occurs because attributes like
`__attribute__((visibility("default")))` are ignored when placed before an `enum class`. This is due to how attributes are parsed in C++.
Moving the attribute after `enum class` ensures it is applied correctly to the type declaration.
Closes#20198
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/20198 from clementperon:main a48ecebea7
PiperOrigin-RevId: 724338159
This test was previously causing a pointer to be taken 2GB out of bounds,
which is UB and can cause problems for tools. Fix the problem by using
a suitably sized buffer instead. With most allocators this will just
result in pages being mmap()ed without being faulted so this test won't
actually end up using 2GB of memory.
PiperOrigin-RevId: 724172825
1. straight forward message set group encoding
2. group encoding but with the fields out of order
3. message set encoded as a typical extension submessage
4. A variant of the former, but I "abuse" a oneof to detect when implementations put the message set fields into the unknown field set.
Go seems to be the only implementation that fails (3) as it will drop these fields entirely. A couple of implementations fail (4).
PiperOrigin-RevId: 723946259
This method has existed since Java 8, released in 2014.
Also adjust the tests so that they verify unsigned integer values that are too big for the signed counterpart (for example, 4294967295 which fits in `uint32` but not `int32`).
We don't use the parallel `Long.parseUnsignedLong` because the existing code handles inputs like `"1.0"`.
PiperOrigin-RevId: 723945649
The TakeFrom() added here is implemented as a deep copy instead of a move-assignment, which can be optimized in a later change without it being visible behavior to users of the API.
PiperOrigin-RevId: 723598316
Create `CheckedGetOrAbort` and `CheckedMutableOrAbort` for repeated_field.h. This is already similarly done for repeated_ptr_field.h.
PiperOrigin-RevId: 723591137
`Map.hash` currently has a bug, which is that it assumes a consistent iteration
order. Experimentally it appears that the iteration order is usually
consistent, but not when there is a collision in the hash table. This can lead
to two equal maps producing different hash values.
This change fixes the problem by making `Map.hash` add up the hash values of
each of its elements, instead of feeding them sequentially into upb's hash
function. Since addition is commutative, this produces a consistent result
regardless of iteration order.
PiperOrigin-RevId: 723545930
This was added by 3f98af287b. I'm not sure why it was needed. But, currently, the supported version is specified in the gemspec(`required_ruby_version`) correctly. So no need to check it inside code.
Closes#19649
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19649 from y-yagi:remove_redundant_version_check 4b1dd06357
PiperOrigin-RevId: 723537424
`std::any` leads to compiler errors in some versions of gcc during
constructibility trait checks.
Now that we can guarantee it, return by reference to avoid extra costs in
copies.
PiperOrigin-RevId: 723478744
- **Link with dbghelp library on Windows**
- **Do not define `PROTOBUF_DESCRIPTOR_WEAK_MESSAGES_ALLOWED` on Windows**
Fixes#16844Closes#20025
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/20025 from avdv:cb/fix-undefined-link-errors-on-win 786535b9df
PiperOrigin-RevId: 723210682
Some APIs (e.g. [BigQuery Storage](ab61c52324/google/cloud/bigquery/storage/v1/protobuf.proto (L39))) use DescriptorProto for schema descriptions. But, in Ruby, there are no methods for that so far.
This PR implements the method for that(`to_proto`) to descriptor classes.
Fixes#12044.
Closes#19971
PiperOrigin-RevId: 723149905
Thomas Van Lenten
Protobuf Team Bot
Heiko Becker
Mike Kruskal
Protobuf Team Bot
Kevin O'Connor
Clément Péron
Peter Collingbourne
Oleh Prypin
Deanna Garcia
deannagarcia
Éamonn McManus
Clayton Knittel
Tony Liao
Adam Cozzette
y-yagi
Claudio Bley
Hong Shin