* Fix NPE during encoding and add regression test for issue 9507.
(cherry picked from commit 58e320a732)
* Implement `respond_to?` in RubyMessage (#9677)
All synthetic methods implemented by `method_missing` are now supported by `respond_to?`.
Fixes issue #9202.
* Fix null pointer exceptions exposed by new regression tests.
* Fix clear_ on oneofs so that it is safe to call repeatedly and so that respond_to? does not depend on whether the oneof is currently cleared.
* Code cleanup: reenable more tests on JRuby.
* Align JRuby behavior with CRuby by throwing a RuntimeError when attempting to assign to a oneof.
(cherry picked from commit 8e7f936696)
* Update protobuf version
* Merge pull request #9727 from mlocati/build-packaged-php-extension
Fix building packaged PHP extension
(cherry picked from commit 7f9901c5f6)
* Update protobuf version
* Update changelogs for 3.20.1-rc1
Co-authored-by: Jason Lunn <jason.lunn@gmail.com>
Co-authored-by: Jorg Brown <jorg.brown@gmail.com>
This commit removes the use of bind() since that function goes against
Bazel best practices:
https://docs.bazel.build/versions/main/external.html#repository-rules-1
The bind() function basically maps a dependency into //external, but
there is no good reason to do this. By mapping dependencies into
//external and relying on this in our own BUILD files, we're forcing
projects that depend on us to do the same. The one bind() call that I
did leave in place was //:python_headers. This one seems to be doing
something complicated I don't fully understand, and I don't want to risk
breaking it.
This change also moves our list of required Maven artifacts into a
constant in protobuf_deps.bzl. This way, projects that depend on us can
refer to this list when they invoke maven_install() and automatically
pull in all the necesary dependencies.
This fixes#9132.
This prepares for a change (internal CL 399474184, to be mirrored out to GitHub) to add a few such annotations in FieldMaskUtil and JsonFormat.
(Technically, this PR is probably not "necessary" because protobuf-util already depends transitively on jsr305. But it's better hygiene to depend on it directly, and the direct dependency could protect against problems if protobuf-util drops some of its other deps -- or if those deps drop their own deps on jsr305.)
* Addresses duplicates identified in #8925
java_export aliases the rule name to the full maven_project_jar which consolidates all deps into a merged jar. This is not what we want for Bazel users.
* Update :util to match
* Addresses duplicates identified in #8925
java_export aliases the rule name to the full maven_project_jar which consolidates all deps into a merged jar. This is not what we want for Bazel users.
* Update :util to match