Google Git
Sign in
pigweed / third_party / github / protocolbuffers / protobuf / 27ee74e6c6f55759eab3dcb7f8bbdce9891bd433
commit27ee74e6c6f55759eab3dcb7f8bbdce9891bd433[log] [tgz]
authorTony Liao <tonyliaoss@google.com>Wed Sep 18 22:24:40 2024 -0700
committerCopybara-Service <copybara-worker@google.com>Wed Sep 18 22:30:06 2024 -0700
tree68b4cc422d76bab118b2610f7ed2af8381f0ddb8
parent921b71958dd2cd57cfba92082b8822e04d8dd08d [diff]
Add map test cases to no_field_presence_test.

Maps behave in a very interesting way if they are set to be implicit-presence
fields.

They present the possibility that the key or value (or both) can be the default
zero value. When that happens, access to the key or the value is unaffected. In
this case, presence is a bit of a meaningless concept. Zero keys are valid as
map indices, and if a map entry is set to zero, it just always exists.

Reflection is a little weird too.
- If you do reflection on a normal integer field and ask if a zero-valued field
  exists, it will tell you that it doesn't exist. This is consistent with what
  "implicit presence" means.
- If you do reflection on a zero integer field that happens to be a map key, it
  will tell you that it exists. Fetching the value of map[0] is equally valid.

(Note that this is not exactly *intended*, but it's just hard to change... and
this implementation results in simpler gencode.)

I'm adding unit tests in no_field_presence_test to cover this quirk.

PiperOrigin-RevId: 676268392
3 files changed
tree: 68b4cc422d76bab118b2610f7ed2af8381f0ddb8
  1. .bcr/
  2. .github/
  3. bazel/
  4. benchmarks/
  5. build_defs/
  6. ci/
  7. cmake/
  8. compatibility/
  9. conformance/
  10. csharp/
  11. docs/
  12. editions/
  13. editors/
  14. examples/
  15. hpb/
  16. hpb_generator/
  17. java/
  18. lua/
  19. objectivec/
  20. php/
  21. pkg/
  22. protos/
  23. python/
  24. ruby/
  25. rust/
  26. src/
  27. third_party/
  28. toolchain/
  29. upb/
  30. upb_generator/
  31. .bazelignore
  32. .bazelrc
  33. .clang-format
  34. .gitignore
  35. .gitmodules
  36. .readthedocs.yml
  37. appveyor.bat
  38. appveyor.yml
  39. BUILD.bazel
  40. Cargo.bazel.lock
  41. Cargo.lock
  42. CMakeLists.txt
  43. CODE_OF_CONDUCT.md
  44. CONTRIBUTING.md
  45. CONTRIBUTORS.txt
  46. fix_permissions.sh
  47. generate_descriptor_proto.sh
  48. global.json
  49. google3_export_generated_files.sh
  50. LICENSE
  51. maven_install.json
  52. MODULE.bazel
  53. PrivacyInfo.xcprivacy
  54. Protobuf-C++.podspec
  55. protobuf.bzl
  56. Protobuf.podspec
  57. protobuf_deps.bzl
  58. protobuf_release.bzl
  59. protobuf_version.bzl
  60. README.md
  61. regenerate_stale_files.sh
  62. SECURITY.md
  63. version.json
  64. WORKSPACE
  65. WORKSPACE.bzlmod
README.md

Protocol Buffers - Google's data interchange format

OpenSSF Scorecard

Copyright 2023 Google LLC

Overview

Protocol Buffers (a.k.a., protobuf) are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. You can learn more about it in protobuf's documentation.

This README file contains protobuf installation instructions. To install protobuf, you need to install the protocol compiler (used to compile .proto files) and the protobuf runtime for your chosen programming language.

Working With Protobuf Source Code

Most users will find working from supported releases to be the easiest path.

If you choose to work from the head revision of the main branch your build will occasionally be broken by source-incompatible changes and insufficiently-tested (and therefore broken) behavior.

If you are using C++ or otherwise need to build protobuf from source as a part of your project, you should pin to a release commit on a release branch.

This is because even release branches can experience some instability in between release commits.

Protobuf Compiler Installation

The protobuf compiler is written in C++. If you are using C++, please follow the C++ Installation Instructions to install protoc along with the C++ runtime.

For non-C++ users, the simplest way to install the protocol compiler is to download a pre-built binary from our GitHub release page.

In the downloads section of each release, you can find pre-built binaries in zip packages: protoc-$VERSION-$PLATFORM.zip. It contains the protoc binary as well as a set of standard .proto files distributed along with protobuf.

If you are looking for an old version that is not available in the release page, check out the Maven repository.

These pre-built binaries are only provided for released versions. If you want to use the github main version at HEAD, or you need to modify protobuf code, or you are using C++, it's recommended to build your own protoc binary from source.

If you would like to build protoc binary from source, see the C++ Installation Instructions.

Protobuf Runtime Installation

Protobuf supports several different programming languages. For each programming language, you can find instructions in the corresponding source directory about how to install protobuf runtime for that specific language:

LanguageSource
C++ (include C++ runtime and protoc)src
Javajava
Pythonpython
Objective-Cobjectivec
C#csharp
Rubyruby
Goprotocolbuffers/protobuf-go
PHPphp
Dartdart-lang/protobuf
JavaScriptprotocolbuffers/protobuf-javascript

Quick Start

The best way to learn how to use protobuf is to follow the tutorials in our developer guide.

If you want to learn from code examples, take a look at the examples in the examples directory.

Documentation

The complete documentation is available at the Protocol Buffers doc site.

Support Policy

Read about our version support policy to stay current on support timeframes for the language libraries.

Developer Community

To be alerted to upcoming changes in Protocol Buffers and connect with protobuf developers and users, join the Google Group.