The `VarintParse()` function is ordinarily called only by the proto parser,
which always provides 16 bytes of "slop" space at the end of the buffer. The
ARM-specific optimized path takes advantage of this by always reading at least
8 bytes. However, this caused some test failures in msan due to unit tests not
providing a sufficient amount of initialized padding. This CL fixes the problem
by making sure the unit tests initialize the full 10-byte buffer and adding a
comment stating that this is a precondition of the function.
PiperOrigin-RevId: 592366291
This CL collapses (strings, bytes) into primitives for message.cc::GetterForViewOrMut.
Strings, bytes, and all primitives have been unified, properly parameterized based on RsType.
Returning $pb$::Mut<$RsType$> and $pb$::View<$RsType$> made this possible.
Note that the vtables for primitives take in an additional type arg, so we've added that.
In addition, strings / bytes (aka stringlikes) require a transform, so that'll be invoked on an as-needed basis.
PiperOrigin-RevId: 592328216
There is a new trimming/AOT warning in JSON formatter enum handling. I have fixed it by suppressing the value.
I also tested the solution with the .NET 8 SDK and suppressed some other warnings that came up (they're already handled).
It would be great to include this fix in a 25.x release.
Closes#14789
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14789 from JamesNK:jamesnk/enum-trimming-warning d64dda15f0
PiperOrigin-RevId: 592306588
Now that Bazel 7.0 has been released, it's time to remove this tech debt.
This has been a no-op since Bazel 5.0, I've been waiting to remove the code for
two years, it's time.
Part of https://github.com/bazelbuild/bazel/issues/14127.
PiperOrigin-RevId: 592219242
Without this it shows up as a spurious warning of dead code from never constructed enum cases (rustc can't 'see' that the value can come across from C++)
PiperOrigin-RevId: 592209619
The x86 microbenchmark speedups here are only representative for packed repeated primitive fields, as they benefit from some improved vectorization.
For normal cases like non-repeated fields, the util/coding microbenchmarks showed roughly 18% for arm and 2-3% for 32 bit x86, 10% for 64 bit x86 (including loop overhead)
PiperOrigin-RevId: 592061508
Now that Bazel 7.0 has been released, it's time to remove this tech debt.
This has been a no-op since Bazel 5.0, I've been waiting to remove the code for
two years, it's time.
Part of https://github.com/bazelbuild/bazel/issues/14127.
PiperOrigin-RevId: 591940644
Latest bundler 2.5.0 release results in the following error: `The last version of bundler (>= 0) to support your Ruby & RubyGems was 2.4.22. Try installing it with gem install bundler -v 2.4.22 bundler requires Ruby version >= 3.0.0. The current ruby version is 2.7.3.183.`
PiperOrigin-RevId: 591288515
Masking a byte by 0xFF does nothing, and the optimizer can see that. I don't think these 0xFF masks do anything in java... but they're in a lot of places so if we remove them entirely it'll be in another CL.
Before (android):
```
ldr w3, [x1, #12]
and w4, w2, #0x7f
orr w4, w4, #0x80
add w5, w3, #0x1 (1)
sxtb w4, w4
```
after:
```
ldr w3, [x1, #12]
orr w4, w2, #0x80
add w5, w3, #0x1 (1)
sxtb w4, w4
```
PiperOrigin-RevId: 591117756
Eric Salo
Adam Cozzette
Jie Luo
Protobuf Team Bot
Hong Shin
James Newton-King
Protobuf Team Bot
John Cater
Thomas Van Lenten
Alyssa Haroldsen
Sandy Zhang
Mike Kruskal