New code should prefer `features.(pb.cpp).string_type`. We can't use the `deprecated=true` option for now due to failing tests.
PiperOrigin-RevId: 643036543
The noop code was causing big .proto files to time out even though it had no
effect in the compilation after optimizing.
We tried avoiding the extra complexity of preprocessor checks on each use, but
it seems necessary for now.
PiperOrigin-RevId: 642691974
For some reason it seems that `pb::*` does not match the type info symbol for
`pb::CppFeatures`. Ordinarily this does not seem to cause problems, but we
received a report about it causing issues with sanitizers:
https://groups.google.com/g/protobuf/c/ytkvjXXdG2g/m/hk7a5JnCAwAJ
For clarity I made the same change for `upb::`, though I don't think this is
strictly necessary since it is covered by the `*pb::*` glob.
PiperOrigin-RevId: 642390692
In translation units relying heavily on protobufs, this leads to a reduction of around 1% of the number of nodes in the AST.
PiperOrigin-RevId: 641170174
Because we parse options into the generated pool for *all* descriptor pool builds, it's important that it's properly initialized. Notably, if the C++ feature extensions haven't been registered we can end up with crashes from files that specify them.
PiperOrigin-RevId: 641043996
The recent github runner image update changes the MSVC version, and InitializeLog now crashes in optimized builds. Until Abseil works with MSVC, we can just log to stderr in protoc.
PiperOrigin-RevId: 641024759
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
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
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
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
This is only reproducible for protos that trigger the lazy build of another proto in the pool that needs feature lifetimes validated. If an error is encountered, we'll end up throwing the lazy build's descriptors into the deferred validation map, but then rolling it back with the original proto. This results in a use-after-free crash.
PiperOrigin-RevId: 636324975
This "feature" hasn't been implemented yet, but this puts a placeholder down to prevent compatibility issues in future editions. Once we provide versioning support on individual feature values, we don't want them becoming usable from edition 2023 protos
PiperOrigin-RevId: 635956805
Some versions of gcc seem to advertise __cpp_nontype_template_args but not
support the argument in some cases.
Only attempt the template parameter if we are using the optimized .reloc
approach.
Fixes https://github.com/protocolbuffers/protobuf/issues/16868
PiperOrigin-RevId: 634787159
# Changes
Remove dead code path -- we don't allow enums to be map keys ([proto2 spec](https://protobuf.dev/programming-guides/proto2/#maps), [proto3 spec](https://protobuf.dev/programming-guides/proto3/#maps)). In other words the case block `case FieldDescriptor::TYPE_ENUM` is dead code. Potential enum type keys will be caught in `default: return lex.Invalid("unsupported map key type");` block below similar to other unsupported map key types like double.
# Motivation
While working on fixing `IgnoreUnknownEnumStringValueInMap` conformance tests for cpp ([related issue](https://github.com/protocolbuffers/protobuf/issues/7392)) I stumbled upon a bug where we pass the wrong `field` parameter to the enum parsing function.
In this scope:
* the variable `field` is a map field of the message that holds the map. This field is not of enum type, it's a repeated message of map entires.
* the variable `key_field` is the key field of the map message entry. This field is the enum type that we need to parse here.
The function is long, so I clarified it here:
```cpp
template <typename Traits>
absl::Status ParseMap(JsonLexer& lex, Field<Traits> field, Msg<Traits>& msg) {
(..)
return lex.VisitObject(
[&](LocationWith<MaybeOwnedString>& key) -> absl::Status {
(..)
return Traits::NewMsg(
field, msg,
[&](const Desc<Traits>& type, Msg<Traits>& entry) -> absl::Status {
auto key_field = Traits::KeyField(type);
switch (Traits::FieldType(key_field)) {
(..)
case FieldDescriptor::TYPE_ENUM: {
MaybeOwnedString key_str = key.value;
auto e = ParseEnumFromStr<Traits>(lex, key_str, /** bug here **/ field);
```
The correct reference should be `key_field`.
Instead of fixing the bug and leaving the dead code, it's better to remove the dead block alltogether.
Closes#16567
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16567 from noom:anton--7392--fix-map-key-nit d992b8a2a6
PiperOrigin-RevId: 634516984
This is an edge case we can't handle properly today. Rather than allowing poorly defined behavior, we'll make this an error condition until we can actually support it. In the future, it may be necessary to upgrade feature files to newer editions.
Closes#16756
PiperOrigin-RevId: 634512378
enabled.
DownCastToGenerated injects the strong reference to T, which makes all instances of CheckTypeAndMergeFrom unique and not candidates for identical code folding.
The strong reference is not needed here in the member function.
PiperOrigin-RevId: 634033477
Mike Kruskal
Protobuf Team Bot
Protobuf Team Bot
Marcel Hlopko
Adam Cozzette
Mark Hansen
Hong Shin
Anton Grbin
Sandy Zhang