Bazel has a 2 minute timeout for their internal `xcrun` call, which can be exceeded on our github runners about 5% of the time. This leads to flakes and opaque errors, but is a one-time cost. Subsequent xcruns finish in seconds, so we can just do an initial call w/o a timeout before running Bazel.
With this change our total flake rate drops from ~30% to nearly 0% for our full suite of tests
See https://github.com/bazelbuild/bazel/issues/17437 for background.
PiperOrigin-RevId: 509944178
This is already generated code, but wasn't included in our generation script. This change makes sure it will be up-to-date, and uses the now-conventional .pb.cs file extension.
This does *not* affect the conformance tests run from Bazel, as they generate the file separately and build the conformance tests using only Program.cs and the freshly-generated code. However, the csharp/src/Google.Protobuf.Conformance/BUILD.bazel still needs to be kept up-to-date with the filename change.
Closes#11880
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11880 from jskeet:generate-conformance 34bb22cc46
PiperOrigin-RevId: 509542860
gcc 12.[12] emits a -Wrestrict warning if compiled
with -O2/-O3 and -std=c++20 enabled when assigning
a string with a single character to a std::string.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
This is benign; disable this broken warning for up to 12.4.
PiperOrigin-RevId: 509358966
- replaces the existing FastV32S1() and FastV64S1() implementations with the FastTV32S1() and FastTV64S1() functions, removing the latter names, and moves the internal template helpers from the header into the .cc file.
- defines PROTOBUF_TC_PARAM_NO_DATA_DECL and PROTOBUF_TC_PARAM_NO_DATA_PASS macros to declare functions not using `data`, and to use in call sites calling these functions.
END_PUBLIC
- adds MUSTTAIL to ToParseLoop() and Error(). The current code was inconsistent on this, and if it doesn't help, it doesn't hurt either and minimizes any possible polition from the call sites.
PiperOrigin-RevId: 509317845
- The support for CI has been removed (no longer needed)
- Update some of the testing targets
- Removed some lesser used options (to simplify)
PiperOrigin-RevId: 509268013
This is done in basically the same way the C++ does this.
It was tested locally be putting `#error` directives in the pre-generated
sources and running the bazel build (it worked).
PiperOrigin-RevId: 509261352
Both 'schedule' and 'workflow_dispatch' are valid alternatives today. What we really want here is anything *except* pull request events.
PiperOrigin-RevId: 509123777
These will still use MSVC as the compiler, but will no longer generate Visual Studio projects for the builds. Visual Studio is particularly bad at parallelizing builds, and is hostile to ccache.
This change also tweaks the ccache setup to prevent unbounded the growth observed in our github caches. Windows builds have had debug symbols stripped to reduce ccache size by a factor of 2x, and ccache maximum have been tweaked so that we persist fewer older builds.
Before this change, each CMake build took 12 minutes on every run (plus some constant overhead from staleness/gcloud), even with caching or on large multi-core runners. No amount of caching or parallelization made any noticeable difference above noise. With this change, we see the following improvements:
- 12 minutes to build from scratch on normal runners (unchanged)
- 4 minutes on 32-core runners from scratch
- 1 minute with optimal caches available on normal runners.
- 30 seconds on 32-core runners with optimal caches
PiperOrigin-RevId: 508799909
Use the bash GHA to ensure WKTs are current, and then just directly invoke
Xcode. This means the script full_mac_build.sh can go back to just being
a simpler helper for folks doing local builds and we can remove all the extra
support that was needed for CI.
PiperOrigin-RevId: 508762464
Changes to these files *can't* be tested in forked PRs, so we should explicitly block them with an error message to explain why.
PiperOrigin-RevId: 508701535
Every where the script is invoked from protoc is already built, and this more
follows the model used by similar scripts for other languages.
PiperOrigin-RevId: 508694936
This fixes a v22 regression for Ruby.
Windows builds of the Ruby package are broken in 3.22.0.rc.2. The reason is, `ruby-upb.h` no longer provides the full path when `#include`ing `utf8_range.h`. See https://github.com/protocolbuffers/protobuf/blob/v22.0-rc2/ruby/ext/google/protobuf_c/ruby-upb.h#L10479 (22.0-rc-2), cf. https://github.com/protocolbuffers/protobuf/blob/v21.12/ruby/ext/google/protobuf_c/ruby-upb.h#L5365 (21.12). The `extconf.rb` build configuration tries to compensate by adding `third_party/utf8_range` to the include path, but does not do so on Windows (i.e. `mingw`) platforms. See https://github.com/protocolbuffers/protobuf/blob/v22.0-rc2/ruby/ext/google/protobuf_c/extconf.rb#L9-L10 (22.0-rc-2), cf. https://github.com/protocolbuffers/protobuf/blob/v21.12/ruby/ext/google/protobuf_c/extconf.rb#L9-L10 (21.12).
We could have fixed this by adding another clause to the if statement for the case `RUBY_PLATFORM =~ /mingw/` and adding the appropriate `-I` flag to `CFLAGS`. However, that `CFLAGS` hack is present in the first place due to a related problem: the usage of `$INCFLAGS` is incorrect.
The `$INCFLAGS` constant in Ruby's `mkmf` is a string in a similar format to `CFLAGS`. It's simply appended to compiler invocations. So when you append new flags to it, you have to (1) provide the flag itself, and (2) precede it with a space to delimit it from the previous entry. In 22.0-rc-2 (and indeed in all earlier versions) the usage is incorrect: it's appending a path to the string without the `-I` and without a space. See https://github.com/protocolbuffers/protobuf/blob/v22.0-rc2/ruby/ext/google/protobuf_c/extconf.rb#L22. Hence, not only does the intended include path not get appended correctly, it also clobbers the previous path in the string. Luckily, the previous path is only `-I$(srcdir)` which happens not to matter for our library. But it does mean that the apparent intent of that line, adding `$(srcdir)/third_party/utf8_range` to the include path, isn't working; hence the code that adds it to `CFLAGS` instead.
(Note that the previous line, adding the path to `$VPATH`, _is_ correct as is, because `$VPATH` is an array.)
So what this PR actually does is fix the `$INCFLAGS` usage so `$(srcdir)/third_party/utf8_range` gets added properly to compiler include paths, for all platforms including Windows. Since that should now be working as intended, we also remove the extra `-I` from CFLAGS. Builds for all platforms should now be able to handle the change to `ruby-upb.h`. This has been tested by running the prototype Ruby build Kokoro job against a patched 22.0-rc-2.
This also needs to be backported to the 22.x branch.
/attn @deannagarciaCloses#11882
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11882 from dazuma:pr/ruby-builds-fix ebb18e0004
PiperOrigin-RevId: 508550039
objc_library really will only build for Apple platforms, so tag it as such.
The objc conformance test really will only build/run on macOS, so tag it as
such.
With these two changes, it should be safer for recursive builds that include
this directory no matter what the host platform is.
PiperOrigin-RevId: 508438744
Since the sources can't reference each other, this is what helps keep them in
sync. Move it out to be a stand alone test in bazel instead of having it wired
into the Xcode projects.
PiperOrigin-RevId: 508429454
Mike Kruskal
Protobuf Team Bot
Protobuf Team Bot
Jon Skeet
Henner Zeller
Martijn Vels
Sandy Zhang
Andrei Tcaci
Daniel Azuma