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
This change moves almost everything in the `upb/` directory up one level, so
that for example `upb/upb/generated_code_support.h` becomes just
`upb/generated_code_support.h`. The only exceptions I made to this were that I
left `upb/cmake` and `upb/BUILD` where they are, mostly because that avoids
conflict with other files and the current locations seem reasonable for now.
The `python/` directory is a little bit of a challenge because we had to merge
the existing directory there with `upb/python/`. I made `upb/python/BUILD` into
the BUILD file for the merged directory, and it effectively loads the contents
of the other BUILD file via `python/build_targets.bzl`, but I plan to clean
this up soon.
PiperOrigin-RevId: 568651768
Hi, I'd like to suggest the adoption of the OpenSSF Scorecard Action.
The scorecard action runs the OpenSSF Scorecard checks on the repository often to provide feedbacks on how to improve (on the security dashboard) and transparency for the users about the current security posture (shown in the badge).
It is also a good way to keep track of new security practices and to provide users easy information about it.
See more about scorecard at [OpenSSF Scorecard](https://github.com/ossf/scorecard) and the [Show off your security score](https://openssf.org/blog/2022/09/08/show-off-your-security-score-announcing-scorecards-badges/)
PiperOrigin-RevId: 568644059
<iostream> embeds a global constructor (to initialize std::cout and such), typically `static ios_base::Init __ioinit;` in libstdc++).
This header is not directly necessary in the common header and has a small impact on every compilation unit that includes it.
As an example, removing that header dependency in turns suppresses 33 global constructors from the firefox core library libxul.
Closes#14174
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14174 from serge-sans-paille:feature/remove-iostream-from-common d3a6be6ee4
PiperOrigin-RevId: 568626744
This allows the compiler to statically detect use-after-free bugs.
This change touches a subset of field types. More changes to follow.
PiperOrigin-RevId: 568586855
This will retry up to 3 times if we hit networks flakes updating our submodules. It will also allow us to easily inject other stability fixes to this step in the future.
PiperOrigin-RevId: 568306356
The most common MergeFrom() scenario is that items are newly appended to an existing repeated field that has never been shrunk. For these cases copy constructing new entries is the cheapest option. This change overloads MergeFrom<> for `std::string`, `StringPiece`, `Message` and `MessageLite`, leaving the remaining templated implementation for all concrete message types supporting arena enabled copy construction, which is implemented as an out of line factory functor implementation.
Going forward we should change `Arena::CreateMaybeMessage()` to return MessageLite* and accept const MessageLite& for copy construction. This will allow us to directly pass Arena::CreateMaybeMessage<T>() into these out of line functions.
PiperOrigin-RevId: 568220325
Adam Cozzette
Hong Shin
Sandy Zhang
Protobuf Team Bot
Samuel Freilich
Protobuf Team Bot
Mike Kruskal
Joshua Haberman
Martijn Vels
Harald Kjær Nielsen
serge-sans-paille
Jie Luo
Lydon Chandra
James Newton-King
Thomas Van Lenten
Arwalk