Note:
This change primarily affects debug + ASAN builds using protobuf arenas.
If this change causes a crash in your debug build, it probably means that
there is a use-after-free bug in your program. This change has already been
implemented and battle-tested within Google for some time.
Oneof messages on the regular heap should not be affected because the memory
they hold are already deleted. Users will already see use-after-free errors
if they attempt to access heap-allocated oneof messages after calling Clear().
When a protobuf message is cleared, all raw pointers should be invalidated
because undefined things may happen to any of the fields pointed to by
mutable_foo() APIs. While destructors may not necessarily be invoked, Clear()
should be considered a pointer invalidation event.
#test-continuous
PiperOrigin-RevId: 689569669
When generating `-I` arguments from `ctx.attr.includes` in
`_proto_gen_impl()`, we might find '.' in the list. That's effectively
source_dir, which we've already handled earlier, and has more
specialized expansion code. Skip it here.
#test-continuous
PiperOrigin-RevId: 689557912
are enabled.
This makes the function a drop-in replacement for `dynamic_cast` when the user
is expecting exceptions to be thrown.
PiperOrigin-RevId: 689419852
Have ExtensionIdentifier have a upb_MiniTableExtension* instead of subclassing a class that is just a plain holder for a upb_MiniTableExtension* with a getter with the same name
We generally want to lean toward composition over inheritance. Without a compelling reason for inheritance, let's prefer composition for clarity, flexibility, and evolvability. Locking oneself into an inheritance hierarchy has marred many a codebase.
PiperOrigin-RevId: 689380813
The JVM regex engine allocates garbage on every match (especially when calling Matcher.usePattern!). Since there are expected to be a lot of tokens, this caused substantial GC overhead.
Direct char scanning also opens the possibility of other optimizations that aren't possible with regexes. For example:
- direct reads from a char[]
- streaming tokenization (rather than reading the complete source text)
PiperOrigin-RevId: 689230675
Without this, `cargo test` tries to extract all rustdoc comments and run them as a unit test. For these snippets, we can't easily actually make such a snippet work, as they explain how codegen would be used.
PiperOrigin-RevId: 688643028
This required making a shim file for a crate to be able to re-export either the _cpp or _upb impl so that it can be one crate that conditionally delegates to the intended one.
PiperOrigin-RevId: 688639897
By just checking for upper-cased characters, rather than digits and lower-cased characters, we have to perform fewer comparisons.
This should be safe because absl::AsciiStrToLower only operates on upper-case characters.
PiperOrigin-RevId: 688453016
Clarifies that reordering `enum` fields (even without changing their IDs) will change the order of the `value` indices. (This means that a seemingly "no-op" change to reorganize enums may affect code that (incorrectly) relied on the order of `value()`.
PiperOrigin-RevId: 688297400
It's not used by generated code, contrary to the comment.
The 2-arg version of the method was used in gencode for one day (2025-04-08 through 09): cl/90574926 to cl/90648831.
PiperOrigin-RevId: 688268752
based one.
This reduces binary size and runtime dispatch costs.
Also, since we are changing the declaration of the type trait, take the opportunity to remove the validator from the template parameters. It can be inferred directly from the type if we add traits for the enum.
PiperOrigin-RevId: 688151072
`Any.TypeName` used `str.split` to extract the second part of the type URL
(potentially the only if there's no slash). `str.rpartition` has the same
effect and avoids constructing a list.
PiperOrigin-RevId: 687385575
This CL migrates messages, enums, and primitive types all onto the same blanket
implementation of the `ProxiedInMapValue` trait. This gets us to the point
where messages and enums no longer need to generate any significant amount of
extra code just in case they might be used as a map value.
There are a few big pieces to this:
- I generalized the message-specific FFI endpoints in `rust/cpp_kernel/map.cc`
to be able to additionally handle enums and primitive types as values. This
mostly consisted of replacing `MessageLite*` parameters with a new `MapValue`
tagged union.
- On the Rust side, I added a new blanket implementation of
`ProxiedInMapValue` in rust/cpp.rs. It relies on its value type to implement
a new `CppMapTypeConversions` trait so that it can convert to and from the
`MapValue` tagged union used for FFI.
- In the Rust generated code, I deleted the generated `ProxiedInMapValue`
implementations for messages and enums and replaced them with
implementations of the `CppMapTypeConversions` trait.
PiperOrigin-RevId: 687355817
There is an old convention that a `proto_library` target with empty `srcs`
should re-export its dependencies. This is sometimes useful as a way of
creating something like an alias target, except that it can point to multiple
dependencies rather than just one.
The `rust_proto_library` aspect currently cannot handle this pattern and will
raise an error if it encounters a `proto_library` without `srcs`. This CL fixes
that problem by updating the `RustProtoInfo` provider generated by the aspect
to include a list of `DepVariantInfo` instead of just one. In the typical case
the provider will have just one `DepVariantInfo`, but this gives us the ability
to return more than one in the case where we're exporting all the dependencies
of a `src`-less `proto_library`.
One thing this CL specifically does not attempt to do is add support for a
`rust_proto_library` directly wrapping a `proto_library` without `srcs`. The
reason for that is that it appears difficult to do in a way that would respect
the layering check. It's also not obvious that we would want to encourage this
pattern anyway. It's still valuable to support `src`-less `proto_library`
targets when they're somewhere else in the transitive dependencies. This way
you can freely create a `rust_proto_library` without having to fix up all your
transitive deps first.
PiperOrigin-RevId: 687344284
When you call a map field setter, we currently make an unnecessary extra copy,
so this CL fixes that problem.
I followed the example of how we already handle this for repeated field
setters. This required adding a new move setter thunk for map fields with the
C++ kernel. Originally I tried instead to add an FFI endpoint that could swap
two `RawMap` pointers, but it turned out to be difficult to implement this in a
way that worked correctly when the two maps are not on the same arena.
PiperOrigin-RevId: 687334655