It is now possible to initialize a field of type `map<string, Message>` with nested dict objects:
```
storage_pb2.Directory(
name='/home/user',
owner='user',
content={
'.bashrc': dict( # <=== dict() allowed here
size=1234,
permissions='PRIVATE',
),
},
)
```
PiperOrigin-RevId: 719437601
This introduces both the basic plumbing for generating metadata (guarded by compiler flags), as well as the initial output of metadata for messages and fields. We largely follows the outline used in the C++ generator.
The second part requires a bit of refactoring on the `FieldGenerator` class since it assumed it was only storing plain string substitutions.
This does not implement cross-references for all symbols (e.g. enums and oneofs); these will be done in followups.
PiperOrigin-RevId: 719269040
This allows us to use `io::Printer::Sub`'s more advanced features, like automatically adding references to symbols in output metadata. We need a new utility class because a lot of code in this generator depends on overwriting placeholders, as well as looking up existing ones.
PiperOrigin-RevId: 719268162
The original code worked in practice only because the pointed-to type is always `void`, and `void**` is convertible to `void*` (ignoring constness).
PiperOrigin-RevId: 719003773
These are currently some of our slowest tests, reliably taking ~26 minutes each. This should speed up our CI significantly
PiperOrigin-RevId: 718963277
Remove some of the legacy union fields from the structs used for
the generated code. The library has already declared it doesn't
support these old formats (via the version check done by the
C pre processor).
PiperOrigin-RevId: 718846100
The type is internal to the generated code/runtime and isn't exposed
in any public api, so go ahead and move it into the Descriptor private
header.
PiperOrigin-RevId: 718383227
The type is internal to the generated code/runtime and isn't exposed
in any public api, so go ahead and move it into the Utilies private
header.
PiperOrigin-RevId: 718032947
The compiler can merge all the different switch cases for all the message alternatives and generates O(1) accessors instead. The switch dispatch is effectively replaced with a virtual function dispatch.
This can significantly reduce code size for oneofs with a lot of message alternatives, specially if it _only_ has message alternatives.
PiperOrigin-RevId: 718025165
It uses the same nodes that Map<> would use for the respectice types.
This makes the type compatible with visitation and removes some custom types
supporting DynamicMapField.
Remove most of the vtable, since this can now be done directly in MapFieldBase without derived type support.
PiperOrigin-RevId: 717984824
Since protobuf codegen is not no-std compatible today (due to usage of std::sync::OnceLock), we should use ::std rather than ::core to slightly reduce our surface area for naming based breakages, including proto_library(name="core"). Only this one spot in the codegen didn't already match that.
PiperOrigin-RevId: 717892640
Each call to `unittest.TestResult.addDuration` increases the total refcount.
The refleak checker now mocks this function to get consistent values.
PiperOrigin-RevId: 717548068
Use popcount with a mask on the has bits to count the number of present fields
instead of checking fields one by one with a conditional.
PiperOrigin-RevId: 716692546
Duration already has a care or two where there are just nanos, but Timestamp doesn't
and the handing of negative values in Timestamp can be a little strange, so this
should probably get a conformance test.
PiperOrigin-RevId: 716668059
We need the minitable plugin to use the C++ plugin framework because it's soon
going to live in the same binary as the Rust code generator. The other plugins
we might as well move just for consistency, and this allows us to delete the
`upb::Plugin` class as well.
PiperOrigin-RevId: 716234662
Remove the naming warnings that would be considered noisy if they were suddenly enabled with no easy way to disable the warnings. The upcoming Edition 2024 naming style enforcement feature and a planned corresponding change to the linter which respects NOLINT comments will cover the cases that these warnings would.
The parser appears to have been accidentally silently suppressed on the CLI path all along; while they were reachable on other usages of the parser, those cases are secondary compared to what we consider the main entry point and so no longer having the naming warnings on those should not locally be a major loss.
PiperOrigin-RevId: 716223703