* Add several fixes for python toolchain
* Fix versin regex
* Make script exit on error
* Fix version regex
* Fix version regex
* Fix version regex
* Fix version regex
* Make test run on the current commit
* Fix test
* Fix test
* Use git to retrieve current commit
* Fix tests
* Fix tests
* Also make linux and mac work on the current commit
* Fix test
GeneratedMessageV3#setUnknownFieldsProto3 was trying to delegate to
setUnknownFields but was inadvertently resulting in infinite recursion.
This commit makes setUnknownFields and setUnknownFieldsProto3 delegate
to a common private method to fix the problem and avoid confusion.
* Use gnu for ruby build because strptime is provided by posix
* Move option to extconf.rb
* Remove unused code in Rakefile
* Add config files for kokoro test
* Use gnu 11
* Define _XOPEN_SOURCE
* Add gnu11 option
* Remove XOPEN
* Try base_cc_flags
* Try config_options
* Move time.h to top
* Try -D_XOPEN_SOURCE=700
* Define XOPEN_SOURCE directly
* Try extconf.rb
* Try CFLAGS
* Try ext.cross_config_options
* Make mac ruby release job fail on error
* Try again
* Try define _XOPEN_SOURCE in extconf.rb
* Try again
* Define __USE_XOPEN
* Remove 2.6.0
* No mingw
* Throw error on mingw
* Remove XOPEN_SOURCE in upb
* Add back mingw
* Remove comment
json_decode automatically convert numeric string to integer, so that
we need to convert it back. However, this will suceed to parse invalid
json data with string field set as integer even though it should have failed.
Because, the failure case is less often than the succeeding case, we decided
to make this change. Users should make sure their data don't use integer for
string fields by themselves.
* Fix python release build.
* Separate config.sh by platform
* Use KOKORO_JOR_NAME to determine the BUILD_COMMIT.
* Use -std=c++14 on MacOS so -latomic can be used.
* Fix python release build.
* Separate config.sh by platform
* Use KOKORO_JOR_NAME to determine the BUILD_COMMIT.
* Use -std=c++14 on MacOS so -latomic can be used.
The draconian heapcheck turns up memory leaks outside our control, such
as ones in libc and in the heapchecker itself. I think for an automated
test it makes more sense for us to use the "strict" heapcheck, since
that already passes and should only report leaks that are within our
control.
Previously, internalAddGeneratedFile has to depend on old non-nested name for sub-messages.
This creates a hard dependency on old generated code for compatibility usage.
If user's code has custome error handler, the deprecation warning in the old generated code
will also be thrown (even though users haven't explicitly depended on the old message name).
To fix this problem, this change added an additional flag in the generated code to tell run
time that it's safe to use new message name. In this way, internalAddGeneratedFile can safely
depend on new name and don't trigger unnecessary deprecation warning.
Paul Yang
Adam Cozzette
Vitaly Buka
Xiang Dai
Michael Matthew Mitchell
Peter Sobot
Bhargava Shastry
Ivan Pizhenko
Bo Yang
Hao Nguyen
Hao Nguyen