Since the fixed/overridable split can occur whenever a feature is introduced or removed, we need to include those editions in the resulting compiled defaults. This does bug only affects edition 2024 and later, where features may be removed or introduced in isolation.
PiperOrigin-RevId: 640267061
We introduce Ptr removal so that our helper functions can be agnostically passed in a Ptr<T> or a T*.
We utilize SFINAE to determine if PtrOrRaw. If the target is const, or not in {T, T*, Ptr<T>}, the template will not match and be discarded (but still compile successfully).
PiperOrigin-RevId: 640198851
message.
Generating declarartions for all nested types is wasteful, and incorrect when
some nested type happens to refer to the parent type. The latter would create
two declrations for the same symbol in the .pb.cc file.
PiperOrigin-RevId: 640142695
If a plugin doesn't support a feature used by a proto file, we can't trust any errors reported by that plugin. We should always report these types of errors first. There could be cases where the plugin doesn't correctly specify its support when it hits an error though, so we should *also* report any plugin errors to avoid masking them.
PiperOrigin-RevId: 639984803
When enabled, all message instances inject their `ClassData` object into `MessageLite` to be stored there instead of the system generated vtable pointer. It replaces all virtual functions and destructor with alternatives using the custom vtable instead.
When disabled, this CL has no effect. The ClassData class is unchanged, and all existing virtual functions remain as they currently are.
Using a custom vtable will allow us to control the ABI of the type, opening the door to more efficient operations.
PiperOrigin-RevId: 639033776
The test I am removing fails on 32-bit ARM, as pointers are 4-byte aligned. `upb_MessageValue` is a union. The alignment of a union is the max. alignment of any of its fields. Among the fields are 8-byte types like u64 and thus `upb_MessageValue` is 8-byte aligned even on 32-bit ARM. 4 != 8 and it fails.
I am split on the usefulness of the test, as I find it somewhat unlikely to catch any divergence between the FFI and C types in the future. I can't imagine a practical scenario where upb_MessageValue would change in C code and this test would fail. IMO our actual unit & integration tests plus the IFTT lints are much better guards.
We could fix the test by testing the alignment of u64 instead of *const c_void, which is always 8 bytes on the hw platforms we care about.
PiperOrigin-RevId: 638976482
Use old-style for loop instead.
This should speed up processes that serialize many unknown fields, and reduce some GC pressure.
PiperOrigin-RevId: 638889708
This should not be needed for generated code, but may be needed for user calls to the public buildFrom method. FileDescriptorProto should really be parsed with java features in the extension registry (like other extensions), but we can handle this in Java runtime to ease editions adoption.
PiperOrigin-RevId: 638715579
This change has no effect in behavior, but makes future changes smaller.
- Make `Message` and `MessageLite` constructors protected.
- Make ClassData objects namespace scope globals instead of function scope. This will allow taking their address without calling a function.
- Replace direct calls to `~MessageLite()` with a helper function.
PiperOrigin-RevId: 638676816
Added the following methods:
serialize_length_prefixed(message: Message, output: io.BytesIO) -> None
parse_length_prefixed(message_class: Type[Message], input_bytes: io.BytesIO) -> Message
The output of serialize_length_prefixed should be BytesIO or custom buffered IO that data should be written to. The output stream must be buffered, e.g. using
https://docs.python.org/3/library/io.html#buffered-streams.
PiperOrigin-RevId: 638375900
This doesn't _actually_ make the C++ Kernel path ever fail yet, but now that the API is a Result<SerializedData, SerializeError> it can be fixed as an implementation detail.
PiperOrigin-RevId: 638329136
`DynamicCastMessage`/`DownCastMessage`.
The target does not necessarily need to be a generated type. For example, it
also supports `Message` itself. This makes the API friendlier to generic code and less verbose.
Replace all uses of dynamic_cast/down_cast/**ToGenerated with the new names.
Also, remove checks for RTTI in tests where we only need the casts to work. They don't need RTTI anymore.
PiperOrigin-RevId: 638278948
This should speed up serializing Extendable Messages (messages with extension ranges declared in their schema) if those message instances have no extensions set inside them at runtime.
PiperOrigin-RevId: 638087120
Protobuf Team Bot
Protobuf Team Bot
Joshua Haberman
Mike Kruskal
Hong Shin
Jakob Buchgraber
Grégoire
Mark Hansen
Sandy Zhang
Manuel
Jie Luo