* 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 will address the following compilation error:
```
src/google/protobuf/compiler/python/python_generator.cc:95:13: warning: unused function 'HasTopLevelEnums' [-Wunused-function]
```
This enables googletest XML output on the macos-next builders, and adds logic to collect the results.
The log collection logic is slightly complex, but it should be reusable in other contexts. The idea is to capture stdout/stderr for build steps along with googletest XML reports into a temporary directory, then stage those into paths expected for artifacts.
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)
The new option will allow us to generate test XML output.
CTest can discover tests from googletest, but it generates one file
per case. We have several thousand cases, so one file each would be
far from optimal. The approach in this change will generate one file
per test (executable).
This enables build logic on the "macos-next" flavor of Kokoro tests.
The current runners use Big Sur with Xcode 13.2.1. This build uses cmake to configure and drive the build through Xcode. Tests are run under ctest.
This doesn't test *all* possibilities (e.g. the field being a
wrapper, or a message field, etc) - but I'm fairly confident that I
found all the places referring to the case.
When following the instructions directly (for developing on Windows) we should end up with a generator that's easy to run for csharp/generate_protos.sh, and we shouldn't end up trying to stage the build output.