This is slightly more efficient and removes explicit dependence
on string layout and alignment. Build tags control use.
Because of what is arguably a bug in go 1.20's treatment of build tags,
is build-tagged to go1.21, not go1.20. (1.20 sees that it matches the
build tag and tries to compile the file, but then demands that it only use
language features from the version mentioned in go.mod. Go 1.21 and 1.22
behave more sensibly.)
Change-Id: I0cfc3b2e5651595edd3a82d9071d918700f961cd
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/545195
Reviewed-by: Cassondra Foesch <cfoesch@gmail.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Lasse Folger <lassefolger@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The grow() method in func did create a new internal byte slice with a
specific size instead of a specific capacity. As the call following
grow() is append() we ended up with a slice larger than needed.
It affects the memory consumption of programs that import generated
protobuf files. As an example with the following:
-- go.mod --
module x
go 1.20
require cloud.google.com/go/appengine v1.6.0
-- main.go --
package main
import _ "cloud.google.com/go/appengine/apiv1/appenginepb"
func main() {}
Running the following a few times:
$ go mod tidy && GODEBUG=inittrace=1 go run . 2>&1 | grep appenginepb
Before:
init cloud.google.com/go/appengine/apiv1/appenginepb @3.4 ms, 0.23 ms clock, 204624 bytes, 231 allocs
init cloud.google.com/go/appengine/apiv1/appenginepb @3.2 ms, 0.17 ms clock, 204688 bytes, 231 allocs
init cloud.google.com/go/appengine/apiv1/appenginepb @2.5 ms, 0.15 ms clock, 204400 bytes, 230 allocs
init cloud.google.com/go/appengine/apiv1/appenginepb @2.5 ms, 0.16 ms clock, 205552 bytes, 234 allocs
After:
init cloud.google.com/go/appengine/apiv1/appenginepb @3.3 ms, 0.19 ms clock, 143440 bytes, 226 allocs
init cloud.google.com/go/appengine/apiv1/appenginepb @2.7 ms, 0.16 ms clock, 144368 bytes, 229 allocs
init cloud.google.com/go/appengine/apiv1/appenginepb @2.8 ms, 0.16 ms clock, 144304 bytes, 229 allocs
init cloud.google.com/go/appengine/apiv1/appenginepb @3.1 ms, 0.16 ms clock, 142864 bytes, 224 allocs
Change-Id: If4ece5d70d6bd9de8a758cb29ce9dffc741c4951
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/465115
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Stapelberg <stapelberg@google.com>
In order to migrate v1 to wrap v2, we need a way to reproduce
the awful enum "names" that v1 used, which was the concatenation of
the proto package with the Go identifier used for the enum.
To support this:
* Move the camel case logic from compiler/protogen to internal/strs
* Add a small stub in internal/impl to expose this functionality
Change-Id: I8ff31daa9ae541e5788dc04d2e89eae1574877e4
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/191637
Reviewed-by: Damien Neil <dneil@google.com>
Rename build tag "proto1_legacy" -> "protolegacy"
to be consistent with the "protoreflect" tag.
Rename flag constant "Proto1Legacy" -> "ProtoLegacy" since
it covers more than simply proto1 legacy features.
For example, it covers alpha-features of proto3 that
were eventually removed from the final proto3 release.
Change-Id: I0f4fcbadd4b5a61c87645e2e5be11d187e59157c
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/189345
Reviewed-by: Damien Neil <dneil@google.com>
In 2014, when proto3 was being developed, there were a number of early
adopters of the new syntax. Before the finalization of proto3 when
it was released in open-source in July 2016, a decision was made to
strictly validate strings in proto3. However, some of the early adopters
were already using invalid UTF-8 with string fields.
The google.protobuf.FieldOptions.enforce_utf8 option only exists to support
those grandfathered users where they can opt-out of the validation logic.
Practical use of that option in open source is impossible even if a user
specifies the proto1_legacy build tag since it requires a hacked
variant of descriptor.proto that is not externally available.
This CL supports enforce_utf8 by modifiyng internal/filedesc to
expose the flag if it detects it in the raw descriptor.
We add an strs.EnforceUTF8 function as a centralized place to determine
whether to perform validation. Validation opt-out is supported
only in builds with legacy support.
We implement support for validating UTF-8 in all proto3 string fields,
even if they are backed by a Go []byte.
Change-Id: I9c0628b84909bc7181125f09db730c80d490e485
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186002
Reviewed-by: Damien Neil <dneil@google.com>
Create a new internal/strs package that unifies common functionality:
* Since protobuf itself pseudo-specifies at least 4 different camel-case
and snake-case conversion functions, we define all variants in one place.
* We move the internal/filedesc.nameBuilder function to this package.
We simplify its implementation to not depend on a strings.Builder fork
under the hood since the semantics we desire is simpler than what
strings.Builder provides.
* We use strs.Builder in reflect/protodesc in its construction of all
the full names. This is perfect use case of strs.Builder since all
full names within a file descriptor share the same lifetime.
* Add an UnsafeString and UnsafeBytes cast function that will be useful
in the near future for optimizing encoding/prototext and encoding/protojson.
Change-Id: I2cf07cbaf6f72e5f9fd6ae3d37b0d46f6af2ad59
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/185198
Reviewed-by: Damien Neil <dneil@google.com>
