This eliminates an ODR violation where users compile and install
Protobuf's C++ runtime without RTTI but do not define
GOOGLE_PROTOBUF_NO_RTTI when compiling their project with
the generated code.
This change updates docstrings and comments so that they will produce nicer
formatting and cross-references from Sphinx. There are a few broad categories of
changes:
- Paramter and attribute docs are updated so that types will be recognized by
Napoleon (https://sphinxcontrib-napoleon.readthedocs.io/en/latest/) This
usually just means moving a colon in the docstring, so
`name: (type) description` becomes `name (type): description`.
- References to other symbols can be cross-references if they have the right
format. For example, "attr_name" might become ":attr:`attr_name`".
https://www.sphinx-doc.org/en/master/usage/restructuredtext/domains.html#cross-referencing-python-objects
- For fenced code blocks, adding a double-colon `::` signifies a literal block.
https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#literal-blocks
- Some bits of docstrings move from docstring to comments. For TODOs, this
means we won't be putting stale (or otherwise unrelated) noise into the docs.
For `Message.DESCRIPTOR`, the change means it gets appropriate documentation.
- There are some wording tweaks for consistency, and some new docstrings
(especially for methods in Message).
For types, I used the convention of `list[Foo]` and `dict(foo, bar)`, which seem
to be common among other Python rst docstrings. Sphinx should generally
recognize both, and cross-links them correctly (both internally and to Python
library documentation). Upgrading to Python3-style type annotations would allow
us to use `sphinx-autodoc-typehints`; the changes in this commit are very
similar to typing-based hints.
This change updates the gtest-version used by Bazel.
Also, `//external:{gtest,gtest_main}` is deprecated so we can remove some
of the uses of the discouraged `bind` function.
RELNOTES[bazel]: Starting with Protobuf 3.13.0, building and running
Protobuf tests requires `@com_google_googletest//:{gtest,gtest_main}`
instead of `//external:{gtest,gtest_main}`. Use
`--@com_google_protobuf//:incompatible_use_com_google_googletest=true`
to verify your workspace is not affected by this change.
Background:
This is a follow-up to the PR that adds sphinx docs.
Read the Docs is a hosting platform for documentation, primarily Python
docs. It supports builds at commit time as well as at specific git
labels to support versioned docs. I have claimed the
protobuf.readthedocs.io project and can add any Googlers who need access
to be able to configure and trigger builds.
https://readthedocs.org/projects/protobuf/builds/ It's also relatively
easy to create a new project to test the documentation builds from a
fork, such as https://readthedocs.org/projects/tswast-protobuf/builds/
About this change:
Once web hooks are configured, Read the Docs will automatically build
the docs for the latest changes on the master branch.
I needed to update `python/setup.py` to support installation from the
root of the repository because Read the Docs does not `cd python` before
installing the protobuf package with `setup.py install`. To support
this, I updated the file paths to use the absolute path to files. The
`__file__` special variable comes in handy for this, as it provides the
path to the `setup.py` file.
A banner is added to the docs when published to readthedocs. This links
to the official documentation and the future home of the stable API
reference on googleapis.dev.
* fix javascript setFieldIgnoringDefault_ logic
* remove package-lock.json
* fix build script to include new UT asset file
Co-authored-by: Daniel Kurka <kurka.daniel@gmail.com>
The Bazel project (https://github.com/bazelbuild/bazel) intends to
enrich its server app's (protobuf-defined) command service's status
message with a structured representation of what, if anything, went
wrong while processing a command. We wish to use custom options to add
metadata to the protobuf constructs involved.
release notes: no
JsonStreamParser::GetNextTokenType() uses HasPrefixString a lot on StringPiece as input. For each call two std::strings are constructed, compared and destroyed. Parsing of json-files with 50-60 MB in debug mode takes minutes.
* Remove protoc release for 32-bit Macs
Apple has been removing the support for 32-bit Mac apps: https://support.apple.com/en-us/HT208436
Our release infrastructure no longer supports building for 32-bit architecture.
* Remove protoc artifact for MacOS 32-bit
* [bazel] Move Java runtime/toolchains into //java
This change moves `java_library` targets from the top-level BUILD file
into `//java/{core,lite,util}` and declares `alias` targets to point to
their new locations (hence, this is not a breaking change).
This will allow users that don't use Java to stop depending on
`@rules_java` (e.g. as requested in
https://github.com/bazelbuild/rules_scala/pull/989#issuecomment-583405161).
Note that there is no intention to deprecate + remove the top-level
targets in the foreseeable future.
* Add BUILD files in //java to java_EXTRA_DIST
* Add failing tests for issues with wrapped values where the value is the default
* Add test for wrapped values without a value set
* Bugfix for wrapper types with default values.
The previous optimizations for wrapper types had a bug that prevented
wrappers from registering as "present" if the "value" field was not
present on the wire.
In practice the "value" field will not be serialized when it is zero,
according to proto3 semantics, but due to the optimization this
prevented it from creating a new object to represent the presence of the
field.
The fix is to ensure that if the wrapper message is present on the wire,
we always initialize its value to zero.
Co-authored-by: Joshua Haberman <jhaberman@gmail.com>
Co-authored-by: Dan Quan <dan@quan.io>
Currently all of our MacOS tests are failing with the error: "autom4te: need GNU m4 1.4 or later: /usr/bin/m4". This is likely to be happening because Kokoro has updated their Xcode version to 11.3.
Currently all of our MacOS tests are failing with the error: "autom4te: need GNU m4 1.4 or later: /usr/bin/m4". This is likely to be happening because Kokoro has updated their Xcode version to 11.3.
Yannic
David L. Jones
Rafi Kamal
Falko Axmann
Tim Swast
Daniel Kurka
Protobuf Team
Artem Kustikov
Mark Schaller
Egor Pugin
wsw2016
Jan Tattermusch
Chuck Atkins
Martin Pärtel