Fixes#12081.
The issue was the call to `MaybeDetachComment`: the conditional assumed that there was a next token, which was on the same line as the previous one, making attribution unclear. However, if there is no next token, we should not detach.
The actual fix is a one-liner. The rest of this PR is updates to the tests to verify this behavior under a handful of scenarios.
Closes#12082
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12082 from jhump:jh/fix-trailing-comment-attribution 767e41cb05
PiperOrigin-RevId: 513046172
* Fix mutability bug in Java proto lite: sub-messages inside of oneofs were not
being set as immutable. This would allow code to get a builder for a
sub-message and modify the original (supposedly immutable) copy.
PiperOrigin-RevId: 511598810
* Add casts to make protobuf compatible with Java 1.8 runtime.
Fix for: https://github.com/protocolbuffers/protobuf/issues/11393
PiperOrigin-RevId: 511807920
---------
Co-authored-by: Protobuf Team Bot <protobuf-github-bot@google.com>
Fix exit code on git commit which was preventing force-push and tagging from running even though these should work without a new commit. An empty commit is probably clearer anyways to show that sync has happened.
In 21.x, depending on "//python:well_known_types_py_pb2" provided a transitive dependency to `compiler/plugin.proto`. That dependency was incorrectly removed for 22.x.
In 22.x, we accidentally omitted stripping the "src" import prefix for plugin.proto. We stripped the prefix in 21.x and for all other well known types in 22.x.
This reverts that unintentional change.
Chocolatey doesn't support any caching, so we're moving back to downloading the exe directly. This issue is responsible for a 5-10% flake rate in our windows cmake builds
PiperOrigin-RevId: 510202223
This fixes some relatively harmless flakiness in our post-submit. If two commits are made within ~5 minutes of each other, the `git push` command will fail because the git workspace isn't up to date.
PiperOrigin-RevId: 510165977
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
Mike Kruskal
deannagarcia
Deanna Garcia
Joshua Humphries
Jerry Berg
Adam Cozzette
zhangskz
Mike Kruskal
Protobuf Team Bot
Protobuf Team Bot