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
This allows to reduce binary bloat (all calls to Clear are now defined out of line) and eliminate redundant calls to clear (since we only call it when it is needed).
PiperOrigin-RevId: 590944438
Do more inlining in certain callers of ParseLoop to avoid the extra stack frame.
This reduces the overall cost of maintaining the stack frames in functions like FastMtS1.
PiperOrigin-RevId: 590943926
## Issue
When an object that is an instance of a string-derived class is passed to a string field in a protobuf message in Ruby, it results in a `Google::Protobuf::TypeError`.
### Steps to reproduce
```rb
~/src/github.com/protocolbuffers/protobuf/ruby/tests ❯❯❯ irb -I .
irb(main):001:0> require 'basic_test_pb'
=> true
irb(main):002:0> myString = Class.new(String)
=> #<Class:0x00000001531540d8>
irb(main):003:0> str = myString.new("foo")
=> "foo"
irb(main):004:0> BasicTest::TestMessage.new(optional_string: "foo")
=> <BasicTest::TestMessage: optional_string: "foo", repeated_int32: [], repeated_int64: [], repeated_uint32: [], repeated_uint64: [], repeated_bool: [], repeated_float: [], repeated_double: [], repeated_string: [], repeated_bytes: [], repeated_msg: [], repeated_enum: []>
irb(main):005:0> BasicTest::TestMessage.new(optional_string: str)
(irb):5:in `initialize': Invalid argument for string field 'optional_string' (given #<Class:0x00000001531540d8>). (Google::Protobuf::TypeError)
irb(main):006:0>
```
## Fix
The issue appears to be caused by the field checking mechanism not properly handling instances of classes that inherit from basic types like String. My proposed solution is to improve the type checking for string fields to consider not just String instances but also instances of subclasses of String.
## Impact
The changes will allow instances of classes derived from String to be passed to string fields without any error.
This is a backwards-compatible change and will not affect the existing behaviour with standard String instances.
Closes#13818
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13818 from NotFounds:support-string-subclass-for-ruby 2d2796c4f9
PiperOrigin-RevId: 590941235
This won't have much effect over the edition zero migration, since enums in any proto2/proto3 file are either exclusively closed/open, respectively. However, it will prefer enum-level features if there's only a single enum
PiperOrigin-RevId: 590642827
Protobuf Team Bot
Eric Salo
Protobuf Team Bot
Thomas Van Lenten
Hong Shin
John Cater
Alyssa Haroldsen
Sandy Zhang
Mike Kruskal
Adam Cozzette
Iori IKEDA