Our Mac test runs recently started failing to download RVM. The issue
appears to be a combination of an SSL certificate expiring and old
OpenSSL versions having a bug preventing them from validating the
replacement certificate: https://github.com/rvm/rvm/issues/5133
This commit works around the problem by downloading RVM from GitHub as
suggested in one of the comments on the issue above.
The Descriptor class now has map_key() and map_value() methods for
accessing the special key and value fields in generated map entry
messages. This commit updates all the relevant code to use these
accessors instead of the clunkier FindFieldByName("key") or
FindFieldByName("value") approach.
This is based on @haberman's changes in #8257. Now that we're using
std::mutex we no longer need to check whether pthreads are available, so
this commit removes references to HAVE_PTHREAD. I left the autotools
build alone, though, since we are likely to drop support for it soon
anyway.
The PyInt_FromLong() conversion function will truncate 64 bit integer
values on 32 bit architectures. We will now use the PyLong_* functions
with the appropriate minimum size for each field.
Note that this commit also switches to the unsigned versions, since the
unknown integer fields have been declared unsigned anyway.
Fixes#6205
These are additional possibilities for --crosstool_top for Android NDK
compilation. Since the NDK doesn't have -lpthread, getting these flags
wrong leads to a linker error.
Fixes: 180084220
other bazel libraries (e.g. rules_docker 0.15.0) require rules_python 0.1.0
or above. running protobuf_deps() before importing rules_docker
will lead to errors.
upgrading rules_python fixes this problem.
* Cannot find any occurrence of `require 'rubygems/tasks` or `Gem::Tasks` in the source code, so I am confident that this development dependency can safely be removed.
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.)