The ABSL logging check seems to prevent the compiler from seeing
that comparing values for equality is equivalent if comparing
with a signed or unsigned zero literal...
Fixes: #11743
PiperOrigin-RevId: 507010435
Fix the macro PROTOBUF_LITTLE_ENDIAN cannot be set correctly on the little endian QNX.
Signed-off-by: wugaoyin <1132954336@qq.com>
Closes#11750
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11750 from WuGaoyin:main 09ec1a19e9
PiperOrigin-RevId: 506979012
Since *.inc is not a common filename suffix, editors and
other tools might not recognize these as c++ and would
not offer language speficific features such as
syntax-highlighting.
This uses the commonly used -*- c++ -*- annotation recongized
by many tools.
PiperOrigin-RevId: 506953120
Pull the first index with jq instead of looking for "main"
Git add all artifacts since "git commit -a" doesn't add new ones
PiperOrigin-RevId: 506933714
It is intended to remove some push/pops and unify the common path
Diff:
https://gcc.godbolt.org/z/4f8a9zsjW
For 64 bit we got rid of extra push/pop. For 32 we think less register pressure and shld is better than ror+test+js. No push/pops. Fun fact that top 32 of 64 bits of intermediate result can be polluted with ones, that does not matter for final assignment of resulting pair
PiperOrigin-RevId: 506846358
This no longer served its original purpose and was actually testing an *older* version of MacOS than the rest of our test suite. This did lock down CMake builds on Mac though, so we'll keep that coverage.
PiperOrigin-RevId: 506776948
This migrates from reusable workflows to composite GHA actions. This has the following advantages:
1) We can split them into smaller, easier to reason about chunks
2) We can reuse them more freely between each other and workflows
3) They don't complicate the job names
4) In theory they'll be easier to test in isolation. While composite actions can't be unit-tested, we can easily break them up into nodejs or docker actions that can be.
As a proof of concept, some of our non-Bazel tests are migrated to GHA as well (CMake + Composer)
Closes#11718
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11718 from protocolbuffers:gha-actions 5403307bc00616e94816aa460813939d8f37a1bd
PiperOrigin-RevId: 506375417
Our repo settings have already been updated to only allow merges from the BTR team and protobuf managers. Except for some very specific circumstances, PRs should *never* be merged and should instead be imported via Copybara.
PiperOrigin-RevId: 506371362
This is a proof of concept that we can experiment with before migrating all of our Kokoro tests to GHA. In addition to the migration, this builds out infrastructure for safe handling of both external and internal contributions. Two of the existing GHA workflows have also been migrated to this system to unify how we handle testing.
To test the new workflow introduced here, you can open PRs to the `gha` branch. This feature branch acts as a staging area for GHA. PRs opened up from this repo will automatically have all tests run on each commit. We will also run them all as post-submits, and continuously on a daily schedule. PRs opened from forked repos will need per-commit approval for each test run, which can be given by adding the `safe for tests` label.
Examples (failures are intentional to show that the PR code is being tested):
- Internal PR: https://github.com/protocolbuffers/protobuf/pull/11679
- Fork PR (approved): https://github.com/protocolbuffers/protobuf/pull/11685
- Fork PR (rejected): https://github.com/protocolbuffers/protobuf/pull/11683
- External PR: https://github.com/protocolbuffers/protobuf/pull/11695Closes#11702
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11702 from protocolbuffers:gha f3a2663896
PiperOrigin-RevId: 506169444
There already are explicit checks in debug builds, but this adds an addition
check within all builds to catch when unknown flags are being passed to the
runtime, which is an indication that the source generation is from a newer
version of the library.
PiperOrigin-RevId: 506091257
When generating Ruby clients for proto3 messages that have a oneof, we generate a hazzer for members of the oneof, not just a hazzer for the oneof itself.
In other words, for a proto like this:
```
syntax = "proto3";
message Foo {
oneof bar {
string baz = 1;
}
}
```
The generated `Foo` will now have a method called `has_baz?`, in addition to the (pre-existing) method `has_bar?`.
I updated the unit tests, and verified that all the tests under `//ruby/...` pass.
Fixes https://github.com/protocolbuffers/protobuf/issues/9561.
Closes#11655
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11655 from shaldengeki:test-ruby-oneof-hazzer a15e474da6
PiperOrigin-RevId: 506090930
We will aim to get binary gems in 3.22.0, but if they aren't done we will do an all source release and bump to 4.22.0 at full release time.
PiperOrigin-RevId: 506075942
Descriptor was relying on the Root for the runtime check, but since the Root is
only startup up when needed, add the debug runtime check to the cases where the
Root isn't started up.
EnumDescriptors are normally started up by fields, but a developer could
directly call the public apis, so add the debug runtime check for safety sake.
PiperOrigin-RevId: 506062884
Protobuf Team Bot
Mike Kruskal
Sandy Zhang
WuGaoyin
Deanna Garcia
Adam Cozzette
Protobuf Team Bot
Charles OuGuo