I realized that as long as we implement `UpbTypeConversions` for enums, we can
easily get the blanket implementation for messages to work for enums as well.
Luckily the blanket implementation also happens to work for non-generated
types, so this gets us down to just one ProxiedInMapValue implementation for
upb.
PiperOrigin-RevId: 673927343
This reduces the total number of instantiations and reduces binary size costs.
It puts an hard upper bound on the total number of instantiations of the template.
PiperOrigin-RevId: 673452657
The `retention` and `target` options have been functional for a long time, so
we can delete these stale comments saying that they do not work yet.
PiperOrigin-RevId: 673401292
- Add overloads that take `absl::Cord` and `std::string&&` as inputs, putting
the burden in the implementation instead of users.
- Hide the APIs that return `std::string*` when the breaking change is
enabled (via `-DPROTOBUF_TEMPORARY_ENABLE_STRING_VIEW_RETURN_TYPE`)....
PiperOrigin-RevId: 673397581
`ClassData`. This reduces code size bloat and runtime costs when using the
custom vtable. It has no significant change for normal mode.
PiperOrigin-RevId: 673010897
This enables enforcement of lifetime specifications on individual enum values for features. It will allow us to add new values to existing features, as well as deprecate/and remove existing values. By default, each value will be scoped to the lifetime spec of its corresponding feature field. However, individual lifetime boundaries can be overridden at the value-level for finer grained control.
In the near-term, this will allow us to deprecate/remove required field presence, and add a stricter utf8 validation feature.
PiperOrigin-RevId: 672710484
* `GenericTypeHandler` used to be forward-declared in message_lite.h and unncessarily friended by `MessageLite`, which was its only use in that source. repeated_ptr_field.h relied on that forward declaration being there, and fully defined `GenericTypeHandler` below the first use.
* `StringPieceField` was forward-declared, and now IWYU'ed.
PiperOrigin-RevId: 672686570
* s/Handler/TypeHandler/g.
* Consistently use aliased `Type` throughout the `GenericTypeHandler` specializations. This makes visual diffing between them easier.
PiperOrigin-RevId: 672665545
Normal mode keeps the existing member function path.
In the future we might change this to a static member function instead to avoid the bloat of the member pointer, but that currently affects normal mode and we want to avoid it for now.
PiperOrigin-RevId: 672552340
The goal of the `names.h` convention is to have a single canonical place where a code generator can define the set of symbols it exports to other code generators, and a canonical place where the name mangling logic is implemented.
Each upb code generator now has its own `names.h` file defining the symbols that it owns & exports:
* `third_party/upb/upb_generator/c/names.h` (for `foo.upb.h` files)
* `third_party/upb/upb_generator/minitable/names.h` (for `foo.upb_minitable.h` files)
* `third_party/upb/upb_generator/reflection/names.h` (for `foo.upbdefs.h` files)
This is a significant improvement over the previous situation where the name mangling functions were co-mingled in `common.h`/`mangle.h`, or sprinkled throughout the generators, with no clear structure for which code generator owns which symbols.
With this structure in place, the visibility lists for the various `names.h` files provide a clear dependency graph for how different generators depend on each other. In general, we want to keep dependencies on the "C" code generator to a minimum, since it is the largest and most complicated of upb's generated APIs, and is also the most prone to symbol name clashes.
Note that upb's `names.h` headers are somewhat unusual, in that we do not want them to depend on C++'s reflection or upb's reflection. Most `names.h` headers in protobuf would use types like `proto2::Descriptor`, but we don't want upb to depend on C++ reflection, especially during its bootstrapping process. We also don't want to force users to build upb defs just to use these name mangling functions. So we use only plain string types like `absl::string_view` and `std::string`.
PiperOrigin-RevId: 672397247
This allows reusing some common string mapping functions in a lightweight library that does not depend on the rest of C++ protobuf.
PiperOrigin-RevId: 672079929
This change renames the helper functions to HasFieldSingular(), SetHasBit(),
ClearHasBit(), and SwapHasBit(), which should hopefully be less confusing.
First of all, the HasBit(), SetBit(), ClearBit(), and SwapBit() methods are all
private so they are easier to change than a public-facing API.
The function named HasBit is called for both proto2 and proto3 fields. For
proto2 fields, it returns true if and only if the hasbit is set -- i.e. if the
field is present. For proto3 fields, it returns true if and only if the field
is nonempty -- i.e. if the field is present.
See documentation here for what "field presence" means:
https://github.com/protocolbuffers/protobuf/blob/main/docs/field_presence.md
Note that in the proto3 case, what this function is doing has nothing to do
with bits!
The name HasFieldSingular is chosen to emphasize the fact that this function
has the same semantics has HasField, only that it's narrowly applied to
"singular" (i.e., non-repeating, non-oneof, non-weak) fields.
HasField itself is not a great name -- IsPresent is probably more appripriate
-- but it is a public API and therefore hard to change. This change at least
makes the two share a similar name.
(I considered `HasPresence` too but that also leaves room for ambiguity: "has
presence" might be interpreted to refer to whether a field is an explicit
presence field or an implicit presence field).
The other helper functions here do manipulate the hasbit directly. Because of
this, they should just make it obvious in the name.
PiperOrigin-RevId: 671966727
This works around a ReturnValueIgnored errorprone issue. There were several other places where this was already done, this is just catching up the remaining two places.
PiperOrigin-RevId: 671878499
<iostream> embeds a global constructor (to initialize std::cout and such), typically `static ios_base::Init __ioinit;` in libstdc++).
Replacing it by <istream>, <ostream> (or both) when possible has an impact on the number of global constructors involved (and thus on the number of instructions executed at startup).
Closes#18069
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18069 from serge-sans-paille:feature/remove-useless-iostream 42d1458235
PiperOrigin-RevId: 671788440
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
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
Adam Cozzette
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
liqipeng
Joshua Haberman
Tony Liao
Cong Liu
serge-sans-paille
Evan Brown