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
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
Protobuf Team Bot
zhangskz
Mike Kruskal
Mike Kruskal
Protobuf Team Bot
Jon Skeet
Henner Zeller
Martijn Vels
deannagarcia