When you have a `T: SomeTrait + ?Sized` and `trait SomeTrait:Sized`, the ?Sized has no effect (its not able to "remove" the requirement).
PiperOrigin-RevId: 654836513
Something has changed between Xcode and xcpretty such that
we don't get full logs when something fails to know what
file/line is actually failing; so stop using it.
PiperOrigin-RevId: 654830446
Also mark the helper as not inline able to avoid the code being over duplicated
within the file with some compiler optimizations turned on.
PiperOrigin-RevId: 654826102
ShouldEmitIfNonDefaultCheck is mostly called in MayEmitIfNonDefaultCheck,
except in one location in GenerateByteSize.
Making MayEmitIfNonDefaultCheck the only caller of ShouldEmitIfNonDefaultCheck
seems like a good application of DRY and reduces the possibility of unintended
divergence in the future. It also makes future changes to serialization logic
easier.
There should be no changes to the resulting generated code.
PiperOrigin-RevId: 654789393
This also changes MessageView and MessageMut to be subtraits of the ViewProxy and MutProxy (which also requires them to have lifetimes now, and a weird extra bounds on ViewProxy)
PiperOrigin-RevId: 654788207
- Now it is arena constructible. Allocates the array, strings, and inner sets in the arena.
- Now it is arena destructible. Will skip destructors when in an arena.
Also, optimize `default_instance()` now that we can provide a `constinit` version of it.
PiperOrigin-RevId: 654743861
Not always emitting the opening brace in this function call can give the caller
a bit more flexibility: for example, it allows for easier use of formatted
string substitutions when both the opening and the closing brace can be
accounted for by the same caller.
PiperOrigin-RevId: 654113509
That way we avoid the extra function call and they behave more like normal
virtual functions.
Has no effect in normal mode.
PiperOrigin-RevId: 654039245
We can't directly use std::atomic because Extension needs to be trivially copyable.
Also move the Extension member functions before the data members to comply with Google C++ style guide.
PiperOrigin-RevId: 653701040
This should provide the roughly same result as ctype, except that it reflects actual behavior rather than the specification in the proto file. VIEW will now be visible, and some subtleties around CORD and PIECE will change.
PiperOrigin-RevId: 653677655
Motivation: these accessors (e.g. size(), Capacity()) will have branches on `is_soo()` so it's best to avoid calling them repeatedly if we can instead save the result in a local variable.
Also update some comments to avoid referring to the names of data members that will no longer exist with SOO.
PiperOrigin-RevId: 653672810
Rather than two traits (MutProxy subtrait of ViewProxy), instead have three traits (MutProxy subtrait of Proxy, and ViewProxy subtrait of Proxy).
This makes things more consistent, including that (MutProxied subtraits Proxied) is now more parallel to (MutProxy subtraits Proxy).
ViewProxy is largely a marker trait here but leaves a spot for methods that should be on ViewProxies but not MutProxies if those do show up later.
PiperOrigin-RevId: 653661953
Use paths.is_normalized and paths.is_absolute from bazel skylib. Upgrade skylib to latest version that has the implementation.
Use copybara for the differences in STRIC_DEPS_FLAG_TEMPLATE.
Implement native_bool_flag to read native flags and use them in proto_library. Those are implemented in such a way, that they can be replaced in place with starlark bool_flag targets.
Implement version check for PackageSpecificationInfo. It's only available after Bazel 6.4.0.
Tests will be submitted in separate PRs.
PiperOrigin-RevId: 653532601
This may save some alloactions if java's intrinsics aren't smart enough to avoid the roundtrip. But most JVMs probably have smart enough intrinsics, so this is probably not going to speed things up, just make the code look nicer.
PiperOrigin-RevId: 653445330
I believe they have intrinsics even for the long-form Integer.compareTo(Integer.valueOf(a), Integer.valueOf(b)) format which avoids the intermediate allocation.
So this probably won't make things faster, just makes the code a little cleaner.
Integer.compare was added in Java 1.7 which seems safe. Added to Android in SDK 19, which is less than the 21 minSDK supported by protobuf: 303239d74d
PiperOrigin-RevId: 653438420
Chris Kennelly
Jie Luo
Protobuf Team Bot
Hong Shin
Thomas Van Lenten
Evan Brown
Tony Liao
Dmitri Gribenko
Éamonn McManus
Mike Kruskal
Joshua Haberman
Mark Hansen
Deanna Garcia
Protobuf Team Bot
Derek Benson