The non-string field setters can bypass the vtables already, the string setters still go through the vtable path here because its more important to let them take an `impl SettableValue` to be able to set either a &str or a &ProtoStr already.
PiperOrigin-RevId: 609705233
It now uses the same prefix as other thunks needed for the proxied type,
so the RawMapThunk helper can be used for enums.
Calling it a "iter next" thunk is misleading.
It does not increment the iterator as "next" implies,
it only gets the current key/value the iterator points to.
PiperOrigin-RevId: 609527442
The purpose is to avoid duplicating the mapping of different types that are only relevant to the serializer but not to the exposed api (e.g. FIXED32 vs INT32)
Treat type=GROUP as rust-type=MESSAGE here which is all that is needed for us to support groups in the rust codegen.
The RustFieldType is parallel to the preexisting FieldDescriptor::CppType which _almost_ does what we need, but it treats Bytes and Strings as the same cpptype which Rust codegen doesn't.
PiperOrigin-RevId: 609416940
Hopefully will make future edits a little easier.
clang-format doesn't do anything with `R"objc(` blocks, and we can't use `R"cc(`
blocks as that gets the ObjC code formatted wrong.
PiperOrigin-RevId: 608678538
Prototiller has subtley different rules about attaching these to objects, and relatively harmless transformations can cause codegen diffs where these move around.
PiperOrigin-RevId: 608648976
Prototiller has subtley different rules about attaching these to objects, and relatively harmless transformations can cause codegen diffs where these move around.
PiperOrigin-RevId: 608402666
Previously, when we call SetRecursiveBuildDispatcher(nullptr), this created a unique_ptr to an AnyInvocable object with a function pointer to a nullptr, which triggers a segmentation fault inside BuildFile.
PiperOrigin-RevId: 607435995
The motivation for this is first that under some combinations of flags it breaks builds and second it's trivial (and possibly zero runtime cost) to fix.
It looks like the possibly bad case "should never happen", but converting this to a null pointer in the error case (which should at least make the failure less problematic) is cheap.
Closes#15846
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/15846 from bcsgh:bcsgh/uninitialized 321d649b51
PiperOrigin-RevId: 607404168
We recently updated the codebase to comply with the Bazel layering check, which
essentially requires any C++ header inclusion to be matched with a build
dependency on a target providing that header.
As part of that, I removed a handful of dependencies from the `//:protobuf`
target, since these dependencies were not set up in a way that respected the
layering check. However, I realized that this may cause a number of breakages,
especially since we did not provide the correct public targets until very
recently.
This change effectively adds back in the missing dependencies, so that projects
which do not yet adhere to the layering check can continue to depend on them
indirectly. This way, we still adhere to the layering check and make it
possible for projects that depend on us to do so, but in most cases we won't
immediately break anyone.
PiperOrigin-RevId: 607021111
Useful for test non-codegen types that have their own parsing logic.
Also forward the `ptr` through the post_loop_handler to allow it to fail.
PiperOrigin-RevId: 606714285