Also, add reference overloads of DynamicCastToGenerated which terminate on failure like dynamic_cast would do on an environment without exceptions.
PiperOrigin-RevId: 571241355
This removes a large chunk of the reflection we need to do during descriptor builds, and will make it possible to migrate descriptor.proto to editions. It also removes some special treatment of the C++ runtime, which happens to have easy access to protoc internals today.
PiperOrigin-RevId: 571177924
This is meant to optimize our editions handling before rolling it out more widely to proto2 and proto3 under the hood. As it's implemented today, every file descriptor would need to allocate its own duplicate FeatureSet for either proto2 or proto3 (plus additional ones per proto2 group).
PiperOrigin-RevId: 571166907
Python 3.12 has removed the `distutils` module, so we need to stop relying on
it. Most of the parts we were using had a straightforward replacement in
`setuptools` or elsewhere in the Python standard library. I couldn't find a
good replacement for `distutils.command.clean`, though. We were only using it
to enable `python setup.py clean`, so I just removed that functionality since
directly invoking setup.py is deprecated anyway.
While I was looking at this I realized that our python/release.sh script is
unused, so I also removed that.
PiperOrigin-RevId: 571035275
This hooks up legacy proto2/proto3 editions, but prohibits them from being used in proto files. These will be hooked up directly to `syntax` declarations in a later change.
PiperOrigin-RevId: 570746314
These exist so that new features can specify their proto2/proto3 defaults. This will allow for easier migration to editions, and also allow us to migrate more proto2/proto3 code paths to common editions code. The latter will provide give us early coverage over a lot more of editions.
PiperOrigin-RevId: 570576252
This is preparation work to merge the vtable with the `ReflectionPayload`
object to reduce the size of MapField by 8 bytes.
PiperOrigin-RevId: 570387900
This makes the file layout a bit more consistent with the `protos ->
protos_generator` pattern. I also replaced the `upbc` namespace with
`upb::generator`.
PiperOrigin-RevId: 569264372
The attempt at a more optimized approach doesn't round-trip all values of `datetime` on all platforms because `datetime.fromtimestamp(tzinfo)` is limited by the range of values accepted by `time.gmtime`, which can be substantially narrower than `datetime.min` to `datetime.max`. (The documentation notes that either `OverflowError` or `OSError` can be raised in that case, and that often this is limited to 1970 through 2038, versus 1 to 9999. See also https://github.com/python/cpython/issues/110042, the use of `gmtime` here seems unnecessary when the tzinfo supports the entire range.) So, supporting that whole range would require need fallback logic that uses this general approach anyways, which then requires a redundant set of tests for error behavior that amounts to a reimplementation of the whole function.
In addition, `datetime.fromtimestamp` doesn't support the full precision of `datetime` (https://github.com/python/cpython/issues/109849), which required adding additional code and an additional assumption (that neither tz offsets were sub-second nor tz changes mid-second).
Added test-cases for `datetime.min` in addition to the ones for `datetime.max`. Adjusted the examples and variable names slightly.
PiperOrigin-RevId: 569259168
It was swapping the arena pointers too when they differed. In that case a full
copy must be made instead. The instances can't change arenas.
PiperOrigin-RevId: 569166797
The previous code did not work because timedelta arithmetic does not do timezone conversions. The result of adding a timedelta to a datetime has the same fixed UTC offset as the original datetime. This resulted in the correct timezone not being applied by `Timestamp.ToDatetime(tz)` whenever the UTC offset for the timezone at the represented moment was not the same as the UTC offset for that timezone at the epoch.
Instead, construct the datetime directly from the seconds part of the timestamp. It would be nice to include the nanoseconds as well (truncated to datetime's millisecond precision, but without unnecessary loss of precision). However, that doesn't work, since there isn't a way to construct a datetime from an integer-milliseconds timestamp, just float-seconds, which doesn't allow some datetime values to round-trip correctly. (This does assume that `tzinfo.utcoffset(dt).microseconds` is always zero, and that the value returned by `tzinfo.utcoffset(dt)` doesn't change mid-second. Neither of these is necessarily the case (see https://github.com/python/cpython/issues/49538), though I'd hope they hold in practice.)
This does take some care to still handle non-standard Timestamps where nanos is more than 1,000,000,000 (i.e. more than a second), since previously ToDatetime handled that, as do the other To* conversion methods.
The bug doesn't manifest for UTC (or any fixed-offset timezone), so it can be worked around in a way that will be correct before and after the fix by replacing `ts.ToDatetime(tz)` with `ts.ToDatetime(datetime.timezone.utc).astimezone(tz)`.
PiperOrigin-RevId: 569012931
Martijn Vels
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
Adam Cozzette
Matt Kulukundis
James Newton-King
Sandy Zhang
Eric Salo
Hong Shin
Samuel Freilich