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
This separate helper for upb dependencies no longer makes sense now that upb
has been merged into the protobuf repo. This change deletes that helper and
moves the upb-specific dependencies into the `protobuf_deps()` function.
I noticed that the Python package deps need to be updated to reflect our
current support level, but I will fix that in a followup CL.
PiperOrigin-RevId: 568997625
This will reduce the number of times our test protos are built, and may fix the flakes we're seeing in aarch64. At the very least, it should reduce them by a factor of 3 and marginally speed up our builds.
PiperOrigin-RevId: 568963559
I also deleted some of upb's dotfiles that are either obsolete (like
`.bazelci/presubmit.yml`) or seem to be superseded by protobuf's dotfiles.
PiperOrigin-RevId: 568873088
Using none ASCII chars for protoc on Windows are not handled well.
This adresses argument file at a location where either directory, or filename contains Unicode chars.
Specifically because MsBuild tool saves argument file in with the UserName appended to the .rsp file.
https://github.com/dotnet/msbuild/pull/9232
But in general we should really handle if none ascii chars are in the path.
Closes#14197
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14197 from hknielsen:support-non-ascii-commandline-args 673d575665
PiperOrigin-RevId: 568722987
Martijn Vels
Matt Kulukundis
Protobuf Team Bot
Mike Kruskal
Protobuf Team Bot
James Newton-King
Sandy Zhang
Eric Salo
Adam Cozzette
Hong Shin
Samuel Freilich
Joshua Haberman
Harald Kjær Nielsen