Project import generated by Copybara.

PiperOrigin-RevId: 500192045
Change-Id: Ia12247cacd1ef63f7d154b294d6f11592f3c9c7a

Author: Protocol Buffer Team

config.toml

@@ -124,13 +124,13 @@ github_project_repo = "https://github.com/protocolbuffers/protobuf"
 # github_branch= "main"
 
 # Google Custom Search Engine ID. Remove or comment out to disable search.
-gcs_engine_id = "d72aa9b2712488cc3"
+# gcs_engine_id = "d72aa9b2712488cc3"
 
 # Enable Algolia DocSearch
 algolia_docsearch = false
 
 # Enable Lunr.js offline search
-offlineSearch = false
+offlineSearch = true
 
 # Enable syntax highlighting and copy buttons on code blocks with Prism
 prism_syntax_highlighting = false

content/programming-guides/encoding.md

@@ -361,7 +361,7 @@ concatenation) even if you do not know their types.
 
 ### Packed Repeated Fields {#packed}
 
-Starting in v2.1.0, `repeated` fields of scalar integer type can be declared as
+Starting in v2.1.0, `repeated` fields of scalar type can be declared as
 "packed". In proto2 this is done with the `[packed=true]`, but in proto3 it is
 the default.
 
@@ -474,10 +474,10 @@ Field numbers may be declared in any order in a `.proto` file. The order chosen
 has no effect on how the messages are serialized.
 
 When a message is serialized, there is no guaranteed order for how its known or
-[unknown fields](/programming-guides/proto#updating) will be written.
-Serialization order is an implementation detail, and the details of any
-particular implementation may change in the future. Therefore, protocol buffer
-parsers must be able to parse fields in any order.
+[unknown fields](/programming-guides/proto#updating) will
+be written. Serialization order is an implementation detail, and the details of
+any particular implementation may change in the future. Therefore, protocol
+buffer parsers must be able to parse fields in any order.
 
 ### Implications
 

content/programming-guides/proto.md

@@ -1312,7 +1312,7 @@ projects we know about, see the
 Individual declarations in a `.proto` file can be annotated with a number of
 *options*. Options do not change the overall meaning of a declaration, but may
 affect the way it is handled in a particular context. The complete list of
-available options is defined in `google/protobuf/descriptor.proto`.
+available options is defined in [`/google/protobuf/descriptor.proto`](https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/descriptor.proto).
 
 Some options are file-level options, meaning they should be written at the
 top-level scope, not inside any message, enum, or service definition. Some

content/programming-guides/proto3.md

@@ -1473,7 +1473,7 @@ A proto3 JSON implementation may provide the following options:
 Individual declarations in a `.proto` file can be annotated with a number of
 *options*. Options do not change the overall meaning of a declaration, but may
 affect the way it is handled in a particular context. The complete list of
-available options is defined in `google/protobuf/descriptor.proto`.
+available options is defined in [`/google/protobuf/descriptor.proto`](https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/descriptor.proto).
 
 Some options are file-level options, meaning they should be written at the
 top-level scope, not inside any message, enum, or service definition. Some

content/reference/cpp/arenas.md

@@ -15,7 +15,8 @@ exactly what C++ code the protocol buffer compiler generates in addition to the
 code described in the
 [C++ Generated Code Guide](/reference/cpp/cpp-generated)
 when arena allocation is enabled. It assumes that you are familiar with the
-material in the [language guide](/programming-guides/proto) and the
+material in the
+[language guide](/programming-guides/proto) and the
 [C++ Generated Code Guide](/reference/cpp/cpp-generated).
 
 ## Why Use Arena Allocation? {#why}
@@ -76,7 +77,7 @@ can see a more extensive [example](#example) at the end of the document.
 ## Arena Class API {#arenaclass}
 
 You create message objects on the arena using the
-[`google::protobuf::Arena`](/reference/cpp/api-docs/google.protobuf.arena)
+[`google::protobuf::Arena`](/reference/cpp/api-docs/google.protobuf.arena.md)
 class. This class implements the following public methods.
 
 ### Constructors {#constructors}
@@ -205,12 +206,12 @@ allocation.
     unspecified state.
 -   `void Swap(Message* other)`: If both messages to be swapped are not on
     arenas or are on the *same* arena,
-    [`Swap()`](/reference/cpp/cpp-generated#message) behaves
-    as it does without having arena allocation enabled: it efficiently swaps the
-    message objects' contents, usually via cheap pointer swaps and avoiding
-    copies at all costs. However, if only one message is on an arena, or the
-    messages are on different arenas, `Swap()` performs *deep copies* of the
-    underlying data. This new behavior is necessary because otherwise the
+    [`Swap()`](/reference/cpp/cpp-generated#message)
+    behaves as it does without having arena allocation enabled: it efficiently
+    swaps the message objects' contents, almost exclusively through cheap
+    pointer swaps, avoiding copies. However, if only one message is on an arena,
+    or the messages are on different arenas, `Swap()` performs *deep copies* of
+    the underlying data. This new behavior is necessary because otherwise the
     swapped sub-objects could have differing lifetimes, leading potentially to
     use-after-free bugs.
 -   `Message* New(Arena* arena)`: An alternate override for the standard `New()`
@@ -292,8 +293,8 @@ allocation is enabled. Otherwise, accessor methods just use the
 
 Currently, string fields store their data on the heap even when their parent
 message is on the arena. Because of this, string accessor methods use the
-[default behavior](/reference/cpp/cpp-generated#string) even
-when arena allocation is enabled.
+[default behavior](/reference/cpp/cpp-generated#string)
+even when arena allocation is enabled.
 
 ### Repeated Fields {#arenarepeated}
 
@@ -339,13 +340,24 @@ methods when arena allocation is enabled.
     occurs. This means that after the swap, each repeated field object holds an
     array on its own arena or on the heap, as appropriate.
 -   `void AddAllocated(SubMessageType* value)`: Checks that the provided message
-    object is on the same arena as the repeated field's arena pointer. If it is
-    on the same arena, then the object pointer is added directly to the
-    underlying array. Otherwise, a copy is made, the original is freed if it was
-    heap-allocated, and the copy is placed on the array. This maintains the
-    invariant that all objects pointed to by a repeated field are in the same
-    ownership domain (heap or specific arena) as indicated by the repeated
-    field's arena pointer.
+    object is on the same arena as the repeated field's arena pointer.
+
+    *   The source and destination are both arena-allocated and on the same
+        arena: the object pointer is added directly to the underlying array.
+    *   The source and destination are both arena-allocated and on different
+        arenas: a copy is made, the original is freed if it was heap-allocated,
+        and the copy is placed on the array.
+    *   The source is heap-allocated and the destination is arena-allocated: No
+        copy is made.
+    *   The source is arena-allocated and the destination is heap-allocated: A
+        copy is made and placed on the array.
+    *   Both source and destination are heap allocated: The object pointer is
+        added directly to the underlying array.
+
+    This maintains the invariant that all objects pointed to by a repeated field
+    are in the same ownership domain (heap or specific arena) as indicated by
+    the repeated field's arena pointer.
+
 -   `SubMessageType* ReleaseLast()`: Returns a heap-allocated message equivalent
     to the last message in the repeated field, removing it from the repeated
     field. If the repeated field itself has a NULL arena pointer (and thus, all
@@ -355,23 +367,27 @@ methods when arena allocation is enabled.
     heap-allocated and returns that copy. In both cases, the caller receives
     ownership of a heap-allocated object and is responsible for deleting the
     object.
+
 -   `void UnsafeArenaAddAllocated(SubMessageType* value)`: Like
     `AddAllocated()`, but does not perform heap/arena checks or any message
     copies. It adds the provided pointer directly to the internal array of
     pointers for this repeated field. See
     [allocated/release patterns](#set-allocated) for details on safe ways to use
     this.
+
 -   `SubMessageType* UnsafeArenaReleaseLast()`: Like `ReleaseLast()` but
     performs no copies, even if the repeated field has a non-NULL arena pointer.
     Instead, it directly returns the pointer to the object as it was in the
     repeated field. See [allocated/release patterns](#set-allocated) for details
     on safe ways to use this.
+
 -   `void ExtractSubrange(int start, int num, SubMessageType** elements)`:
     Removes `num` elements from the repeated field, starting from index `start`,
     and returns them in `elements` if it is not NULL. If the repeated field is
     on an arena, and elements are being returned, the elements are copied to the
     heap first. In both cases (arena or no arena), the caller owns the returned
     objects on the heap.
+
 -   `void UnsafeArenaExtractSubrange(int start, int num, SubMessageType**
     elements)`: Removes `num` elements from the repeated field, starting from
     index `start`, and returns them in `elements` if it is not NULL. Unlike

content/reference/java/java-generated.md

@@ -15,8 +15,8 @@ proto3 generated code are highlighted—note that these differences are in
 the generated code as described in this document, not the base message
 classes/interfaces, which are the same in both versions. You should read the
 [proto2 language guide](/programming-guides/proto) and/or
-[proto3 language guide](/programming-guides/proto3) before reading this
-document.
+[proto3 language guide](/programming-guides/proto3)
+before reading this document.
 
 Note that no Java protocol buffer methods accept or return nulls unless
 otherwise specified.
@@ -165,9 +165,9 @@ then `Foo` will include fast implementations of all methods, but will implement
 the `MessageLite` interface, which only contains a subset of the methods of
 `Message`. In particular, it does not support descriptors or reflection.
 However, in this mode, the generated code only needs to link against
-`libprotobuf-lite.jar` instead of `libprotobuf.jar`. The "lite" library is
-much smaller than the full library, and is more appropriate for
-resource-constrained systems such as mobile phones.
+`libprotobuf-lite.jar` instead of `libprotobuf.jar`. The "lite" library is much
+smaller than the full library, and is more appropriate for resource-constrained
+systems such as mobile phones.
 
 The `Message` interface defines methods that let you check, manipulate, read, or
 write the entire message. In addition to these methods, the `Foo` class defines
@@ -288,8 +288,8 @@ that modify the value are defined in the builder only.
 
 Note that method names always use camel-case naming, even if the field name in
 the `.proto` file uses lower-case with underscores
-([as it should](/programming-guides/style)). The case-conversion works
-as follows:
+([as it should](/programming-guides/style)). The
+case-conversion works as follows:
 
 1.  For each underscore in the name, the underscore is removed, and the
     following letter is capitalized.
@@ -329,7 +329,8 @@ The compiler will generate the following methods only in the message's builder:
     `hasFoo()` will return `false` and `getFoo()` will return the default value.
 
 For other simple field types, the corresponding Java type is chosen according to
-the [scalar value types table](/programming-guides/proto#scalar).
+the
+[scalar value types table](/programming-guides/proto#scalar).
 For message and enum types, the value type is replaced with the message or enum
 class.
 
@@ -376,7 +377,8 @@ The compiler will generate the following methods only in the message's builder:
     `getFoo()` will return the default value for the field's type.
 
 For other simple field types, the corresponding Java type is chosen according to
-the [scalar value types table](/programming-guides/proto#scalar).
+the
+[scalar value types table](/programming-guides/proto#scalar).
 For message and enum types, the value type is replaced with the message or enum
 class.
 
@@ -427,88 +429,89 @@ the generated [enum type](#enum).
 For this field definition:
 
 ```proto
-repeated string foo = 1;
+repeated string foos = 1;
 ```
 
 The compiler will generate the following accessor methods in both the message
 class and its builder:
 
--   `int getFooCount()`: Returns the number of elements currently in the field.
--   `String getFoo(int index)`: Returns the element at the given zero-based
+-   `int getFoosCount()`: Returns the number of elements currently in the field.
+-   `String getFoos(int index)`: Returns the element at the given zero-based
     index.
--   `ProtocolStringList getFooList()`: Returns the entire field as a
+-   `ProtocolStringList getFoosList()`: Returns the entire field as a
     `ProtocolStringList`. If the field is not set, returns an empty list.
 
 The compiler will generate the following methods only in the message's builder:
 
--   `Builder setFoo(int index, String value)`: Sets the value of the element at
+-   `Builder setFoos(int index, String value)`: Sets the value of the element at
     the given zero-based index.
--   `Builder addFoo(String value)`: Appends a new element to the field with the
+-   `Builder addFoos(String value)`: Appends a new element to the field with the
     given value.
--   `Builder addAllFoo(Iterable<? extends String> value)`: Appends all elements
+-   `Builder addAllFoos(Iterable<? extends String> value)`: Appends all elements
     in the given `Iterable` to the field.
--   `Builder clearFoo()`: Removes all elements from the field. After calling
-    this, `getFooCount()` will return zero.
+-   `Builder clearFoos()`: Removes all elements from the field. After calling
+    this, `getFoosCount()` will return zero.
 
 For other simple field types, the corresponding Java type is chosen according to
-the [scalar value types table](/programming-guides/proto#scalar).
+the
+[scalar value types table](/programming-guides/proto#scalar).
 For message and enum types, the type is the message or enum class.
 
 #### Repeated Embedded Message Fields
 
-For message types, `setFoo()` and `addFoo()` also accept an instance of the
+For message types, `setFoos()` and `addFoos()` also accept an instance of the
 message's builder type as the parameter. This is just a shortcut which is
 equivalent to calling `.build()` on the builder and passing the result to the
 method. There is also an additional generated method:
 
--   `Builder addFoo(int index, Field value)`: Inserts a new element at the given
-    zero-based index. Shifts the element currently at that position (if any) and
-    any subsequent elements to the right (adds one to their indices).
+-   `Builder addFoos(int index, Field value)`: Inserts a new element at the
+    given zero-based index. Shifts the element currently at that position (if
+    any) and any subsequent elements to the right (adds one to their indices).
 
 In addition, the compiler generates the following additional accessor methods in
 both the message class and its builder for message types, allowing you to access
 the relevant sub-builders:
 
--   `FooOrBuilder getFooOrBuilder(int index)`: Returns the builder for the
+-   `FooOrBuilder getFoosOrBuilder(int index)`: Returns the builder for the
     specified element, if it already exists, or throws
     `IndexOutOfBoundsException` if not. If this is called from a message class,
     it will always return a message (or throw an exception) rather than a
     builder. Calling this method on builders will not create a sub-builder for
     the field.
--   `List<FooOrBuilder> getFooOrBuilderList()`: Returns the entire field as an
+-   `List<FooOrBuilder> getFoosOrBuilderList()`: Returns the entire field as an
     unmodifiable list of builders (if available) or messages if not. If this is
     called from a message class, it will always return an immutable list of
     messages rather than an unmodifiable list of builders.
 
 The compiler will generate the following methods only in the message's builder:
 
--   `Builder getFooBuilder(int index)`: Returns the builder for the element at
+-   `Builder getFoosBuilder(int index)`: Returns the builder for the element at
     the specified index, or throws `IndexOutOfBoundsException` if the index is
     out of bounds.
--   `Builder addFooBuilder(int index)`: Inserts and returns a builder for a
+-   `Builder addFoosBuilder(int index)`: Inserts and returns a builder for a
     default message instance at the specified index. The existing entries are
     shifted to higher indices to make room for the inserted builder.
--   `Builder addFooBuilder()`: Appends and returns a builder for a default
+-   `Builder addFoosBuilder()`: Appends and returns a builder for a default
     message instance.
--   `Builder removeFoo(int index)`: Removes the element at the given zero-based
+-   `Builder removeFoos(int index)`: Removes the element at the given zero-based
     index.
--   `List<Builder> getFooBuilderList()`: Returns the entire field as an
+-   `List<Builder> getFoosBuilderList()`: Returns the entire field as an
     unmodifiable list of builders.
 
 #### Repeated Enum Fields (proto3 only)
 
 The compiler will generate the following additional methods in both the message
 class and its builder:
 
--   `int getFooValue(int index)`: Returns the integer value of the enum at the
+-   `int getFoosValue(int index)`: Returns the integer value of the enum at the
     specified index.
--   `List<java.lang.Integer> getFooValueList()`: Returns the entire field as a
+-   `List<java.lang.Integer> getFoosValueList()`: Returns the entire field as a
     list of Integers.
 
 The compiler will generate the following additional method only in the message's
 builder:
 
--   `Builder setFooValue(int index, int value)`: Sets the integer value of the
+-   `Builder setFoosValue(int index, int value)`: Sets the integer value of the
     enum at the specified index.
 
 #### Name Conflicts
@@ -520,15 +523,15 @@ number appended to the end.
 For these field definitions:
 
 ```proto
-int32 foo_count = 1;
-repeated string foo = 2;
+int32 foos_count = 1;
+repeated string foos = 2;
 ```
 
 The compiler will first rename them to the following:
 
 ```proto
-int32 foo_count_1 = 1;
-repeated string foo_2 = 2;
+int32 foos_count_1 = 1;
+repeated string foos_2 = 2;
 ```
 
 The accessor methods will subsequently be generated as described above.
@@ -564,7 +567,8 @@ The compiler will generate the following methods only in the message's builder:
         `getExampleNameCase()` will return `EXAMPLENAME_NOT_SET`.
 
 For other simple field types, the corresponding Java type is chosen according to
-the [scalar value types table](/programming-guides/proto#scalar).
+the
+[scalar value types table](/programming-guides/proto#scalar).
 For message and enum types, the value type is replaced with the message or enum
 class.
 
@@ -602,7 +606,8 @@ The compiler will generate the following methods only in the message's builder:
 
 ## Any
 
-Given an [`Any`](/programming-guides/proto3#any) field like this:
+Given an [`Any`](/programming-guides/proto3#any) field
+like this:
 
 ```proto
 import "google/protobuf/any.proto";
@@ -994,8 +999,8 @@ sends requests to a particular `BlockingRpcChannel`.
 ## Plugin Insertion Points {#plugins}
 
 [Code generator plugins](/reference/cpp/api-docs/google.protobuf.compiler.plugin.pb)
-that want to extend the output of the Java code generator may insert code of
-the following types using the given insertion point names.
+that want to extend the output of the Java code generator may insert code of the
+following types using the given insertion point names.
 
 -   `outer_class_scope`: Member declarations that belong in the file's wrapper
     class.