This test validates that upb Python targets can be built successfully even if
Python is not installed locally.
I also updated our pinned upb version to pull in some recent fixes needed for
this test run.
PiperOrigin-RevId: 559504790
This change adds test runs for GCC, Windows, and Mac. The 32-bit ASAN test
turned out to be somewhat difficult to migrate, so I left a TODO for that one.
I made sure to give each build environment its own cache prefix, so that we
don't end up with artifacts built by different toolchains conflicting with each
other in the same cache.
PiperOrigin-RevId: 559197655
There are still a bunch more test runs to migrate, but this change adds a few
more that were unblocked by the `exclude-targets` flag.
PiperOrigin-RevId: 558206606
My editor reformatted this file to add a missing newline, and this ended up
breaking the test. The added newline caused there to be a newline in the middle
of the Bazel command. So this change adds the missing newline and fixes up the
Bazel command by using the `>-` syntax to treat this as a multiline string
without adding any newlines.
PiperOrigin-RevId: 558149295
This change moves the upb Fastbuild, Optimized, and FastTable test runs over to
the protobuf repo CI in preparation for moving the upb codebase itself. There
are a bunch more test runs to move, but this initial change handles the easy
ones first.
I also updated our pinned upb version to the current head to pick up some
recent fixes.
PiperOrigin-RevId: 557486174
https://github.com/protocolbuffers/protobuf/pull/13204 refactored the Ruby object cache to use a key of `LL2NUM(key_val)` instead of `LL2NUM(key_val >> 2)`. On 32-bit systems, `LL2NUM(key_val)` returns inconsistent results because a large value has to be stored as a Bignum on the heap. This causes cache lookups to fail.
This commit restores the previous behavior of using `ObjectCache_GetKey`, which discards the lower 2 bits, which are zero. This enables a key to be stored as a Fixnum on both 32 and 64-bit platforms.
As https://patshaughnessy.net/2014/1/9/how-big-is-a-bignum describes, a Fixnum uses:
* 1 bit for the `FIXNUM_FLAG`.
* 1 bit for the sign flag.
Therefore the largest possible Fixnum value on a 64-bit value is 4611686018427387903 (2^62 - 1). On a 32-bit system, the largest value is 1073741823 (2^30 - 1).
For example, a possible VALUE pointer address on a 32-bit system:
0xff5b4af8 => 4284173048
Dropping the lower 2 bits makes up for the loss of range to these flags. In the example above, we see that shifting by 2 turns the value into a 30-bit number, which can be represented as a Fixnum:
(0xff5b4af8 >> 2) => 1071043262
This bug can also manifest on a 64-bit system if the upper bits are 0xff.
Closes#13481Closes#13494
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13494 from stanhu:sh-fix-ruby-protobuf-32bit d63122a6fc
PiperOrigin-RevId: 557211768
Clang and GCC differ on how they detect Address Sanitizer. Support both.
Closes#1424
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/upb/pull/1424 from protocolbuffers:asan-clang 491a5ee4cfd24c8eb281f894de0cf4384525c46a
PiperOrigin-RevId: 553805994
This flag was added to Protobuf and submitted separately due to version skew between repos.
This attempts to fix the following error from local and release settings both matching.
```
ERROR: /workspace/_build/out/external/upb/python/dist/BUILD.bazel:251:9: Illegal ambiguous match on configurable attribute "platform" in @upb//python/dist:binary_wheel:
@upb//python/dist:linux_x86_64_local
@upb//python/dist:windows_x86_64
Multiple matches are not allowed unless one is unambiguously more specialized or they resolve to the same value. See https://bazel.build/reference/be/functions#select.
```
PiperOrigin-RevId: 553226261
If you are running an older version of PHP, you can install a previous release
of the protobuf PHP extension by running pecl install protobuf-3.23.3.
PiperOrigin-RevId: 546056449
These are designed to only run once daily in "quiet" hours to avoid race conditions. While isn't very harmful, it does cause our monitoring to show an artificial increase in flakes.
PiperOrigin-RevId: 544883830
It's not clear what happens if both C++17/C++20 and C++14 are specified, so it's possible this was effectively disabling those tests.
PiperOrigin-RevId: 544763031
This has caused repeated issues due to the fact that it checks the entire repo. Most recently, it decided to complain about a typo in a file that hasn't been touched in 5 years.
PiperOrigin-RevId: 540356791
Our automation can't currently update release branches, so we need to enable staleness tests as presubmits to force manual regeneration.
PiperOrigin-RevId: 540094169
- Do some minimal sanity testing on every PR
- Only run the staleness tests on a daily schedule or explicit runs.
- Add 23.x to the checks
PiperOrigin-RevId: 537952151
Mike Kruskal
Adam Cozzette
Joshua Haberman
Eric Salo
Stan Hu
Jason Lunn
Sandy Zhang
Joshua Haberman
Matt Kulukundis
Tomo Suzuki
Marcel Hlopko
Joyce
Carlos O'Ryan