This is a no-op cleanup. The methods are package-private so shouldn't be an API break.
I'm about to add some more tests here. This just makes writing the tests easier , as they don't have to catch IOException any more.
PiperOrigin-RevId: 671592242
This ensures that the test for exponential resizing (for amortized linear time)
actually looks exponential.
Previously, we saw in tests that if we add 1000 element-lists 10x in a row, sometimes
we grow the backing array by 6000 bytes twice in a row. (12024 - 18024 - 24024).
Now the test looks much more consistently exponential.
PiperOrigin-RevId: 671577283
Previously, we only make extensions immutable if they were in the FieldSet's
array, maximum size 16. The overflow entries in the TreeMap weren't made
immutable.
PiperOrigin-RevId: 671564444
I will fix this test in the next CL.
This test runs on both `GeneratedMessage` and `GeneratedMessageLite` variants, so we need to first check if `nested instanceof GeneratedMessageLite`, otherwise on the full-variant test, we get `isMutable()` method found on `GeneratedMessage`.
PiperOrigin-RevId: 671563318
This turned out to be much easier for upb than for C++. This CL pretty much
just does a cut-and-paste of the `ProxiedInMapValue` implementation from the
upb code generator to the runtime. This should help a bit with code size since
it removes the need to generate six `ProxiedInMapValue` implementations per
message.
PiperOrigin-RevId: 671438289
Import both the public and private header into impls when the
private is needed.
Also update the tests to use more complete imports.
PiperOrigin-RevId: 671388271
This past reliance doesn't work well with Swift, and the sources
were trying to over hand optimize to minimize rebuilds, and that
likely isn't worth the trouble, so explicit imports.
The remaining places that still use them are where they are
needed within the header to deal with relationships between
the local definitions or where there is a cycle between the
headers and it allows either one to be imported first and still
get a complete definition in the using context.
PiperOrigin-RevId: 671379912
This version works where both sides are the same message, messageview or messagemut type, but not any mix of them (e.g. cannot compare a message against its corresponding view).
PiperOrigin-RevId: 671091099
This also increases compliance by adding `default_applicable_licenses` to several `BUILD` files that previously did not have it.
PiperOrigin-RevId: 670784686
This avoids some extra copies and garbage generation.
There's still the extra default 10-sized backing array created by default in
ProtobufArrayList which isn't fixed yet, which we see in allocation tests. That's from `ensureXIsMutable()` which allocates a new list without awareness of the list's size. Maybe we can fix that later: b/362848901.
PiperOrigin-RevId: 670766317
I've tried to keep the hot part of the loop (not null) in the loop without
requiring an extra function call, and only extracted the cold part (null
handling) to avoid repetition.
PiperOrigin-RevId: 670760103
The way AnyMetadata works is by holding two pointers to the fields of
google.protobuf.Any, and its methods `PackFrom` and `UnpackTo` mutates these
pointers directly.
This works but is a bit overcomplicated. A whole new object is created to
mutate members of Any directly, breaking isolation. Each Any object will also
need to unnecessarily create room to hold an AnyMetadata object, which is at
minimum the size of two pointers.
By removing AnyMetadata and using free functions, the call site passes
`const Value& foo()` and `Value* mutable_foo()` directly into `PackFrom` and
`UnpackTo`. This is more idiomatic and will play well with hasbits.
The only catch here is that in some templated implementations of `PackFrom` and
`UnpackTo`, caller will need access to T::FullMessageName(), which is in
private scope. The workaround here is to have a single templated helper
function that is made into a friend of google.protobuf.Any, so that it has the
right visibility.
PiperOrigin-RevId: 670722407
These are very old unit-tests that appear to have been written to provide some conformance capabilities before we had more comprehensive solutions. Today, they should be already covered by our conformance tests and create unnecessary noise.
The goal of this change is to simply desynchronize the Java and C++ text format golden files. Java at least seems to be using these for a dual-purpose for both locking down conformance and unit-testing text format behaviors.
PiperOrigin-RevId: 670596733
When the user adds `option deprecated = true` for an `enum` or `message`, we
should add the `[[deprecated]]` attribute to the generated C++ `enum` or
`class`.
PiperOrigin-RevId: 670583253
The old generated code suppressed warnings broadly to support protobuf
deprecations like this showing to users, but the previous commit does
provide a debug log statement for the usages.
PiperOrigin-RevId: 670581568
We need this type to be trivial and standard layout because we directly read
its contents in Rust. This change removes its user-defined constructors so that
it becomes a trivial type.
PiperOrigin-RevId: 670572557
The symbol renaming support has assumed folks would define a
custom version of the macro, but if a developer does renaming
just by #defining the class, the extension singleton names
required manual handing, by changing to just wrap the class
in the macro and using the compiler string concat support
it becomes easier as just the class name remapping can do
the work for extensions.
PiperOrigin-RevId: 670536928
Mark Hansen
Protobuf Team Bot
Eric Salo
Hong Shin
Protobuf Team Bot
Evan Brown
Adam Cozzette
Thomas Van Lenten
Derek Benson
Joshua Haberman
Mike Kruskal
Tony Liao
y-yagi
Hood Chatham