Add the prototype package which provides constructors for
protoreflect.{Enum,Message,Extension}Type.
Switch all usages of the internal/prototype equivalent to the new package.
Switch all custom implementions of {Enum,Message}Type to the new package.
Change-Id: Ia9dae6fed4f2b90e55c123627044a7faf098c4b1
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/178438
Reviewed-by: Damien Neil <dneil@google.com>
The prototype package was initially used by generated reflection support,
but has now been replaced by internal/fileinit.
Eventually, this functionality should be deleted and re-written in terms
of other components in the repo.
Usages that prototype currently provides (but should be moved) are:
* Constructing standalone messages and enums, which is behavior we should
provide in reflect/protodesc. The google.protobuf.{Enum,Type} are well-known
proto messages designed for this purpose.
* Constructing placeholder files, enums, and messages.
* Consructing protoreflect.{Message,Enum,Extension}Types, which are protobuf
descriptors with associated Go type information.
Change-Id: Id7dbefff952682781b439aa555508c59b2629f9e
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167383
Reviewed-by: Damien Neil <dneil@google.com>
This CL takes a significantly different approach to generating support
for protobuf reflection. The previous approach involved generating a
large number of Go literals to represent the reflection information.
While that approach was correct, it resulted in too much binary bloat.
The approach taken here initializes the reflection information from
the raw descriptor proto, which is a relatively dense representation
of the protobuf reflection information. In order to keep initialization
cost low, several measures were taken:
* At program init, the bare minimum is parsed in order to initialize
naming information for enums, messages, extensions, and services declared
in the file. This is done because those top-level declarations are often
relevant for registration.
* Only upon first are most of the other data structures for protobuf
reflection actually initialized.
* Instead of using proto.Unmarshal, a hand-written unmarshaler is used.
This allows us to avoid a dependendency on the descriptor proto and also
because the API for the descriptor proto is fundamentally non-performant
since it requires an allocation for every primitive field.
At a high-level, the new implementation lives in internal/fileinit.
Several changes were made to other parts of the repository:
* cmd/protoc-gen-go:
* Stop compressing the raw descriptors. While compression does reduce
the size of the descriptors by approximately 2x, it is a pre-mature
optimization since the descriptors themselves are around 1% of the total
binary bloat that is due to generated protobufs.
* Seeding protobuf reflection from the raw descriptor significantly
simplifies the generator implementation since it is no longer responsible
for constructing a tree of Go literals to represent the same information.
* We remove the generation of the shadow types and instead call
protoimpl.MessageType.MessageOf. Unfortunately, this incurs an allocation
for every call to ProtoReflect since we need to allocate a tuple that wraps
a pointer to the message value, and a pointer to message type.
* internal/impl:
* We add a MessageType.GoType field and make it required that it is
set prior to first use. This is done so that we can avoid calling
MessageType.init except for when it is actually needed. The allows code
to call (*FooMessage)(nil).ProtoReflect().Type() without fearing that the
init code will run, possibly triggering a recursive deadlock (where the
init code depends on getting the Type of some dependency which may be
declared within the same file).
* internal/cmd/generate-types:
* The code to generate reflect/prototype/protofile_list_gen.go was copied
and altered to generated internal/fileinit.desc_list_gen.go.
At a high-level this CL adds significant technical complexity.
However, this is offset by several possible future changes:
* The prototype package can be drastically simplified. We can probably
reimplement internal/legacy to use internal/fileinit instead, allowing us
to drop another dependency on the prototype package. As a result, we can
probably delete most of the constructor types in that package.
* With the prototype package significantly pruned, and the fact that generated
code no longer depend on depends on that package, we can consider merging
what's left of prototype into protodesc.
Change-Id: I6090f023f2e1b6afaf62bd3ae883566242e30715
Reviewed-on: https://go-review.googlesource.com/c/158539
Reviewed-by: Herbie Ong <herbie@google.com>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
This change preserves consistency with CL/157077,
where New returns a value closer to the reflective type.
Change-Id: I85bfdae24e1ce1a10c3c7b939420fa1043bff743
Reviewed-on: https://go-review.googlesource.com/c/157078
Reviewed-by: Damien Neil <dneil@google.com>
Most usages of New actually prefer to interact with the reflective view
rather than the native Go type. Thus, change New to return that instead.
This parallels reflect.New, which returns the reflective view
(i.e., reflect.Value) instead of native type (i.e., interface{}).
We make the equivalent change to KnownFields.NewMessage, List.NewMessage,
and Map.NewMessage for consistency.
Since this is a subtle change where the type system will not always
catch the changed type, this change was made by both changing the type
and renaming the function to NewXXX and manually looking at every usage
of the the function to ensure that the usage correctly operates
on either the native Go type or the reflective view of the type.
After the entire codebase was cleaned up, a rename was performed to convert
NewXXX back to New.
Change-Id: I153fef627b4bf0a427e4039ce0aaec52e20c7950
Reviewed-on: https://go-review.googlesource.com/c/157077
Reviewed-by: Damien Neil <dneil@google.com>
Drop the protoreflect.ProtoEnum type (containing a single method
returning a protoreflect.Enum) and make generated enum types
directly implement protoreflect.Enum instead.
Messages have a two-level type split (ProtoMessage and Message) to
minimize conflicts between reflection methods and field names. Enums
need no such split, since enums do not have fields and therefore have
no source of conflicts.
Change-Id: I2b6222e9404253e6bfef2217859e1b760ffcd29b
Reviewed-on: https://go-review.googlesource.com/c/156902
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
The purego tag (see https://golang.org/issue/23172) is a community agreed
upon signal that a given build environment does not support unsafe.
The appengine environment is supposed to respect this tag, but does not
properly do so. Add this tag back in until they fix their environment.
Change-Id: I9a70062be4339c2e1a93cac31d387698c561b8aa
Reviewed-on: https://go-review.googlesource.com/c/154743
Reviewed-by: Damien Neil <dneil@google.com>
Introduce a protoreflect.OptionsMessage interface type to represent
options messages. The protoreflect package can't deal with concrete
options types, to avoid dependency cycles; OptionsMessage serves both
as documentation and a single point to define the constraints we apply
to options.
Change the constraints on options from ProtoMessage to interface{} to
permit use of option message types which only implement the v1
proto.Message interface.
This still leaves a requirement in the internal/legacy package that
options implement protoreflect.ProtoMessage, since that package now uses
the v2 Unmarshal.
Change-Id: I547518ab2c3b90c3911ef641b05b169d50a4b33a
Reviewed-on: https://go-review.googlesource.com/c/154877
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Add fields to the Message and Field builder structs which hold the value
of MessageOptions.map_entry, FieldOptions.packed, and FieldOptions.weak
options. Remove all access to the contents of options messages from the
prototype package.
Change IsPacked to always return false for unpackable field types,
which is consistent with the equivalent C++ API.
This change helps avoid dependency cycles between prototype and the
options messages. (Previously this was resolved by accessing options
with reflection, but just breaking the dependency from prototype to the
options message is cleaner and simpler.)
Change-Id: I756aefe2e04cfa8fea31eaaaa0b5a99d4ac9e851
Reviewed-on: https://go-review.googlesource.com/c/153517
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
The DescriptorProto method was originally intended to return a raw descriptor.
However, that functionality will be responsibility of the protodesc package
in the near future.
Also document that any callers of Options must import the descriptor package.
This is reasonable since any usage of that method will almost always be of
the form:
fd.Options().(*descriptorpb.FieldOptions)
Change-Id: I1085f02305faef8dd724e0cb3ad45ac12bd5df0a
Reviewed-on: https://go-review.googlesource.com/c/153497
Reviewed-by: Damien Neil <dneil@google.com>
These properties of descriptors are currently missing and makes it impossible
to convert a FileDescriptorProto into one of the structured Go representations
and convert it back to a proto message without loss of information.
Furthermore, ReservedRanges and ReservedNames has semantic importance
to text serialization.
Change-Id: Ic33c30020ad51912b143156b95f47a4fb8da3503
Reviewed-on: https://go-review.googlesource.com/c/153019
Reviewed-by: Damien Neil <dneil@google.com>
Considerable thought was given to whether a seperate ExtensionRanges interface
should be made that encapsulates FieldNumbers with an Options method.
However, I decided against this design for the following reasons:
* Extension ranges share syntax with reserved numbers and fields.
Why is extension ranges so special that it can have options, while the other
two currently do not? How do we know that those other two won't grow options
in the future? If they do, then those APIs can be expanded in the same way as
how extension range options is being expanded here today.
* Extension range options stand out like a sore thumb compared to the other
eight options. The other options correspond with a named declaration and have
a full protobuf name that they are associated with. Extension range options
is the only options that is not correlated with a full name.
* Extension range options are an extremely rarely used feature and
it seems unfortunate complicating the common case with additional structure.
Change-Id: Ib284a0b798c57dc264febe304692eee5b9c8e91b
Reviewed-on: https://go-review.googlesource.com/c/153018
Reviewed-by: Damien Neil <dneil@google.com>
Add pseudo-hidden functions to register the concrete Go type used for
the optional types. Also, augment protoc-gen-go to specially generate the
descriptor proto to register these types.
This change does not add validation logic yet to ensure that the correct option
types are passed to the API.
Change-Id: I5decc897e14b4bf570a61cf17b57a066a2a0f9d7
Reviewed-on: https://go-review.googlesource.com/c/153017
Reviewed-by: Damien Neil <dneil@google.com>
Custom descriptor types would want to benefit from descriptor formatting.
As such, move the logic out from prototype into an internal package for
the benefit of usages outside the prototype package.
Change-Id: I4bb2144221e656aa36909d33a77189fe084f700b
Reviewed-on: https://go-review.googlesource.com/c/152777
Reviewed-by: Herbie Ong <herbie@google.com>
In order to generate descriptor.proto, the generated code would want to depend
on the prototype package to construct the reflection data structures.
However, this is a problem since descriptor itself is one of the dependencies
for prototype. To break this dependency, we do the following:
* Avoid using concrete *descriptorpb.XOptions messages in the public API, and
instead just use protoreflect.ProtoMessage. We do lose some type safety here
as a result.
* Use protobuf reflection to interpret the Options message.
* Split out NewFileFromDescriptorProto into a separate protodesc package since
constructing protobuf reflection from the descriptor proto obviously depends
on the descriptor protos themselves.
As part of this CL, we check in a pre-generated version of descriptor and plugin
that supports protobuf reflection natively and switchover all usages of those
protos to the new definitions. These files were generated by protoc-gen-go
from CL/150074, but hand-modified to remove dependencies on the v1 proto runtime.
Change-Id: I81e03c42eeab480b03764e2fcbe1aae0e058fc57
Reviewed-on: https://go-review.googlesource.com/c/152020
Reviewed-by: Damien Neil <dneil@google.com>
Add a Proto prefix before the Unwrap method to reduce the probability that
it would ever conflict with a method of the same name that a
custom implementation of Enum, Message, List, or Map may have.
Change-Id: I628bf8335583f2747ab4589f3e6ff82e4501ce98
Reviewed-on: https://go-review.googlesource.com/c/151817
Reviewed-by: Herbie Ong <herbie@google.com>
Add the scalar package to reduce dependencies on the v1 proto runtime package.
It may very well be the case that these functions should be exposed in the
public API of v2, but that is not a decision we need to make now.
Change-Id: Ifbc6d15311ba5837909ac72af47c630a80a142ef
Reviewed-on: https://go-review.googlesource.com/c/151402
Reviewed-by: Herbie Ong <herbie@google.com>
The use of math/rand in serialization is to provide some form of instability
to the output to provide a clear signal to the user that the should not
depend on the the property of stability. However, it is reasonable that users
expect the output for these to be deterministic.
As such, add a detrand package that provides deterministic, yet unstable
randomization functionality.
Since this package hashes the binary, it does impose a small initialization cost:
Benchmark 100000 20712 ns/op 480 B/op 6 allocs/op
Change-Id: I232d0fea1789a4278079837a67ee2f63474a4364
Reviewed-on: https://go-review.googlesource.com/c/151340
Reviewed-by: Herbie Ong <herbie@google.com>
Add GoType to the list of accessors that can be pretty-printed.
Useful for debugging.
Change-Id: Ib2a240249ca5bf0176cb77fa5edc639d44ae0561
Reviewed-on: https://go-review.googlesource.com/c/150537
Reviewed-by: Herbie Ong <herbie@google.com>
The terminology Vector does not occur in protobuf documentation at all,
so we should rename the Go use of the term to something more recognizable.
As such, all instances that match the regexp "[Vv]ect(or)?" were replaced.
The C++ documentation uses the term "Repeated", which is a reasonable name.
However, the term became overloaded in 2014, when maps were added as a feature
and implementated under the hood as repeated fields. This is confusing as it
means "repeated" could either refer to repeated fields proper (i.e., explicitly
marked with the "repeated" label in the proto file) or map fields. In the case
of the C++ reflective API, this is not a problem since repeated fields proper
and map fields are interacted with through the same RepeatedField type.
In Go, we do not use a single type to handle both types of repeated fields:
1) We are coming up with the Go protobuf reflection API for the first time
and so do not need to piggy-back on the repeated fields API to remain backwards
compatible since no former usages of Go protobuf reflection exists.
2) Map fields are commonly represented in Go as the Go map type, which do not
preserve ordering information. As such it is fundamentally impossible to present
an unordered map as a consistently ordered list. Thus, Go needs two different
interfaces for lists and maps.
Given the above situation, "Repeated" is not a great term to use since it
refers to two different things (when we only want one of the meanings).
To distinguish between the two, we'll use the terms "List" and "Map" instead.
There is some precedence for the term "List" in the protobuf codebase
(e.g., "getRepeatedInt32List").
Change-Id: Iddcdb6b78e1e60c14fa4ca213c15f45e214b967b
Reviewed-on: https://go-review.googlesource.com/c/149657
Reviewed-by: Damien Neil <dneil@google.com>
Implement support for extension fields for messages that use the v1
data structures for extensions. The legacyExtensionFields type wraps a
v1 map to implement the v2 protoreflect.KnownFields interface.
Working on this change revealed a bug in the dynamic construction of
message types for protobuf messages that had cyclic dependencies (e.g.,
message Foo has a sub-field of message Bar, and Bar has a sub-field of Foo).
In such a situation, a deadlock occurs because initialization code depends on
the very initialization code that is currently running. To break these cycles,
we make some systematic changes listed in the following paragraphs.
Generally speaking, we separate the logic for construction and wrapping,
where constuction does not recursively rely on dependencies,
while wrapping may recursively inspect dependencies.
Promote the MessageType.MessageOf method as a standalone MessageOf function
that dynamically finds the proper *MessageType to use. We make it such that
MessageType only supports two forms of messages types:
* Those that fully implement the v2 API.
* Those that do not implement the v2 API at all.
This removes support for the hybrid form that was exploited by message_test.go
In impl/message_test.go, switch each message to look more like how future
generated messages will look like. This is done in reaction to the fact that
MessageType.MessageOf no longer exists.
In value/{map,vector}.go, fix Unwrap to return a pointer since the underlying
reflect.Value is addressable reference value, not a pointer value.
In value/convert.go, split the logic apart so that obtaining a v2 type and
wrapping a type as v2 are distinct operations. Wrapping requires further
initialization than simply creating the initial message type, and calling it
during initial construction would lead to a deadlock.
In protoreflect/go_type.go, we switch back to a lazy initialization of GoType
to avoid a deadlock since the user-provided fn may rely on the fact that
prototype.GoMessage returned.
Change-Id: I5dea00e36fe1a9899bd2ac0aed2c8e51d5d87420
Reviewed-on: https://go-review.googlesource.com/c/148826
Reviewed-by: Herbie Ong <herbie@google.com>
The Go type descriptors protoreflect.{Enum,Message,Extension}Type are simple
wrappers over protoreflect.{Enum,Message,Extension}Descriptor with a small
number of additional methods. It is very unlikely that more will be added in
the near future.
For this reason, construct the types directly using arguments to the constructor
function, as opposed to taking in another struct (which was originally done
to provide flexibility in-case we needed more fields).
Furthmore, rename GoNew and New.
Change-Id: Ic7fb5bc250cdb2761ae03b388b5147ff50f37d15
Reviewed-on: https://go-review.googlesource.com/c/148822
Reviewed-by: Herbie Ong <herbie@google.com>
Most usages extensions are only for fields that have a singular message
as the type. In such a sitation, the Go type and constructors are determined
by the provided protoreflect.MessageType and is certainly what the user wanted.
Custom extensions constructors are mainly useful if the user wants to use their
own type to represent repeated fields. For example, we use *[]T to represent
repeated fields, while a user may want to use their own opaque type.
However, this is such a niche use-case that it is not worth supporting given
that there is a workaround:
type MyExtensionType struct {
protoreflect.ExtensionType
}
func (x MyExtensionType) GoNew() interface{} {
... // return my custom value
}
func (x MyExtensionType) GoType() reflect.Type {
... // return my custom type
}
func (x MyExtensionType) ValueOf(v interface{}) protoreflect.Value {
... // convert my custom type to a protoreflect.Value
}
func (x MyExtensionType) InterfaceOf(v protoreflect.Value) interface{} {
... // convert a protoreflect.Value to my custom type
}
Change-Id: Iafc838b1c95b0ffc8583461ee9eb327bd3ce9c3c
Reviewed-on: https://go-review.googlesource.com/c/148820
Reviewed-by: Herbie Ong <herbie@google.com>
Implement the constructor for protoreflect.ExtensionType.
The constructor is more complicated than NewGoEnum and NewGoMessage because
it is responsible for providing the wrappers to present *[]T as a
protoreflect.Vector.
There are no tests since we need the follow-up logic in internal/impl to actually
make use of extensions. A subsequent CL will add that logic and comprehensively
test extensions.
Change-Id: I2d7893de299fe40be2ccedd8f39a92c40c41e59a
Reviewed-on: https://go-review.googlesource.com/c/147578
Reviewed-by: Herbie Ong <herbie@google.com>
Default values for enums are specified by name, not number. An enum
may contain multiple values with different names but the same number.
Representing the default as a protoreflect.Value containing an EnumNumber
can discard information.
Add a method returning the EnumValueDescriptor.
Change-Id: If8beee3f81d41c4f9af45423252603b86949c7a5
Reviewed-on: https://go-review.googlesource.com/c/145158
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Extensions are normally thought of as a proto2 feature.
However, proto3 actually allows declarations of field extensions *only*
if they extend messages declared in descriptor.proto.
In such a situation it is not well defined whether the extension field
operates under proto2 or proto3 properties.
In some ways, such declarations are proto3-like.
For example, the declaration in the proto file still follows
proto3's syntactical grammar (e.g., no "optional" label required)
and proto3 semantics (e.g., default values are not allowed).
However, in other ways, such declarations are proto2-like.
For example, a repeated field of numeric scalars is not automatically packed.
This property is determined by the following test.
Compile the following proto file:
syntax = "proto3";
import "google/protobuf/descriptor.proto";
extend google.protobuf.FieldOptions {
repeated sint32 test_field = 20181023;
}
then compile and run a C++ program with the following snippet:
google::protobuf::FieldOptions m;
m.AddExtension(test_field, 1);
m.AddExtension(test_field, 2);
m.AddExtension(test_field, 3);
fstream output("out", ios::out | ios::trunc | ios::binary);
m.SerializeToOstream(&output);
which produces an "out" file with the following contents:
$ pbdump -sints 20181023 out
Message{
Tag{20181023, Varint}, Svarint(1),
Tag{20181023, Varint}, Svarint(2),
Tag{20181023, Varint}, Svarint(3),
}
which is indicative that packed encoding was not used by default (proto2-like).
If we repeat the above experiment and explicit set "[packed = true]",
then packed encoding is used:
$ pbdump -sints 20181023 out
Message{
Tag{20181023, Bytes}, LengthPrefix{Svarint(1), Svarint(2), Svarint(3)},
}
Note that this change does not mean that field extensions are always proto2
since the experiment above does not conclusively prove that. Thus, the Syntax
on extensions derived from the descriptor protos may still report proto3.
The behavior of packed encoding with regards to proto3 says:
In proto3, repeated fields of scalar numeric types use packed encoding by default.
One way to interpret this is:
In proto3 (messages), repeated fields of scalar numeric types use packed encoding by default.
In which case packedness is a property of the message's syntax
rather than the field's syntax (if such a distinction exists).
Since only proto2 messages can be extended, we can safely assume that all
extension fields use proto2 semantics for IsPacked.
Change-Id: Iae595c6d88c6e252cae7552cae083bad42f2494a
Reviewed-on: https://go-review.googlesource.com/c/144278
Reviewed-by: Damien Neil <dneil@google.com>
Without resolving the question of whether an extension field is always proto2
or sometimes proto3, just make it impossible to construct a standalone extension
field of the proto3 syntax.
By dropping the syntax field from the constructor, we can just assume that the
syntax is always proto2. There is no benefit for creating a proto3 standalone
extension, so there is no loss of functionality.
In the unlikely future where there needs to be distinction, we can add the field
back into the descriptor. The zero value of protoreflect.Syntax is invalid,
so we can determine if the user did not set that field.
Change-Id: Ie93fa55de96f29553fb04ff6649bbea79a144407
Reviewed-on: https://go-review.googlesource.com/c/144279
Reviewed-by: Damien Neil <dneil@google.com>
Add a method to fetch descriptor options. Since options are proto
messages (e.g., google.protobuf.FieldOptions), and proto message
packages depend on the protoreflect package, returning the actual option
type would cause a dependency cycle. Instead, we return an interface
value which can be type asserted to the appropriate concrete type.
Add options support to the prototype package.
Some of the prototype constructors included fields (such as
Field.IsPacked) which represent information from the options
(such as google.protobuf.FieldOptions.packed). To avoid confusion about
the canonical source of information, drop these fields in favor of the
options.
Drop the unimplemented Descriptor.DescriptorOptionsProto.
Change-Id: I66579b6a7d10d99eb6977402a247306a78913e74
Reviewed-on: https://go-review.googlesource.com/c/144277
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
In order for the v2 rollout to be as seamless as possible, we need to support
the situation where a v2 message depends on some other generated v1 message that
may be stale and does not support the v2 API. In such a situation, there needs
to be some way to wrap a legacy message or enum in such a way that it satisfies
the v2 API.
This wrapping is comprised of two parts:
1) Deriving an enum or message descriptor
2) Providing an reflection implementation for messages
This CL addresses part 1 (while part 2 has already been partially implemented,
since the implementation applies to both v1 and v2).
To derive the enum and message descriptor we rely on a mixture of parsing the
raw descriptor proto and also introspection on the fields in the message.
Methods for obtaining the raw descriptor protos were added in February, 2016,
and so has not always been available. For that reason, we attempt to derive
as much information from the Go type as possible.
As part of this change, we modify prototype to be able to create multiple
standalone messages as a set. This is needed since cyclic dependencies is allowed
between messages within a single proto file.
Change-Id: I71aaf5f977faf9fba03c370b1ee17b3758ce60a6
Reviewed-on: https://go-review.googlesource.com/c/143539
Reviewed-by: Damien Neil <dneil@google.com>
A .proto source file with no 'package' statement may still contain
references to descriptors within the file.
Change-Id: I86e942c9c06e5a2915e9722162e0455ffa9ba2ab
Reviewed-on: https://go-review.googlesource.com/c/140899
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
According to google.protobuf.FieldDescriptorProto.default_value documentation:
>>>
For strings, contains the default text contents (not escaped in any way).
For bytes, contains the C escaped value. All bytes >= 128 are escaped.
<<<
Thus, use the default value ad-verbatim if the kind is a string.
For the bytes kind, we use the text format hack to unescape the string,
since the text format uses the same unescape syntax as C due to its heritage.
Change-Id: I79e6d4d7e8f0d1ebedccecb9424a49384485589d
Reviewed-on: https://go-review.googlesource.com/138515
Reviewed-by: Damien Neil <dneil@google.com>
This change was created by running:
git ls-files | xargs sed -i "s|google.golang.org/proto|github.com/golang/protobuf/v2|g"
This change is *not* an endorsement of "github.com/golang/protobuf/v2" as the
final import path when the v2 API is eventually released as stable.
We continue to reserve the right to make breaking changes as we see fit.
This change enables us to host the v2 API on a repository that is go-gettable
(since go.googlesource.com is not a known host by the "go get" tool;
and google.golang.org/proto was just a stub URL that is not currently served).
Thus, we can start work on a forked version of the v1 API that explores
what it would take to implement v1 in terms of v2 in a backwards compatible way.
Change-Id: Ia3ebc41ac4238af62ee140200d3158b53ac9ec48
Reviewed-on: https://go-review.googlesource.com/136736
Reviewed-by: Damien Neil <dneil@google.com>
The minimum supported version is currently Go1.10 since we use strings.Builder
for a fairly significant optimization when constructing all of the descriptor
full names.
The strings.Builder implementation is not particularly complicated,
so just fork it into our code. The golang/protobuf and the golang/go
projects share the same authors and copyright license.
Change-Id: Ibb9519dbe756327a07369f10f80c15761002b5e7
Reviewed-on: https://go-review.googlesource.com/136735
Reviewed-by: Damien Neil <dneil@google.com>
Derive the compact string from the multi string output.
This makes is such that we don't have to update two sets of golden data.
Change-Id: I94b94f1094b448539f8bee234be83ac7186fdd30
Reviewed-on: https://go-review.googlesource.com/135335
Reviewed-by: Herbie Ong <herbie@google.com>
Add constructors for creating protoreflect.{Enum,Message}Type,
which extend the protobuf descriptor with Go type information.
Rationale for API:
* NewGoEnum and NewGoMessage take in a struct instead of multiple
function parameters to provide future flexibility in adding more parameters.
* NewGoEnum and NewGoMessage take in a pointer to a struct so that generated
code can batch allocate these structs and convert them to them to EnumTypes
or MessageTypes efficiently. In other words, allocations are entirely in the
control of the caller.
* The user provides a New function as opposed to a reflect.Type or pointer to
the concrete type to support dynamic protobufs, where a single Go type may be
used to represent multiple protobuf types.
* The New functions take in an EnumType or MessageType since an implementation
for dynamic protobufs would need to close over these types. All statically
generated messages can ignore that argument.
There are no tests added since these are just wrappers;
they will be heavily exercised by other code.
Change-Id: I9fca44e06f3388375be7eaca94f8fd75c17233a3
Reviewed-on: https://go-review.googlesource.com/135356
Reviewed-by: Damien Neil <dneil@google.com>
protoreflect.Value.IsNull was inverted to become IsValid in CL 134998.
However, that CL was submitted without a rebase,
which broke the build since CL 135255 added a few more usages of IsNull.
Change-Id: I5e52fb880ffc92e9d8f6cab30848e65b2d6dcbdc
Reviewed-on: https://go-review.googlesource.com/135337
Reviewed-by: Damien Neil <dneil@google.com>
Change the API to use explicit Has/Clear methods instead of relying on the
"invalid" form of Value to represent nullability.
There are several reasons for this change:
* Much of the ecosystem around protobufs do not care about nullability alone.
For example, for the encoder to determine whether to emit a field:
it needs to first check if a field is nulled, and if not, it still needs to go
through a series of type-assertion to check whether the value is the zero value.
It is much easier to be able to just call Has.
* It enables representing the default value as part of the value API, rather
than only as part of the descriptor API.
* The C++ API also uses explicit has and clear methods. However, we differ from
them by defining Has for proto3 scalars (while C++ panics instead).
For internal consistency, we also use a Has/Clear API for Maps.
Change-Id: I30eda482c959d3e1454d72d9fc761c761ace27a6
Reviewed-on: https://go-review.googlesource.com/134998
Reviewed-by: Damien Neil <dneil@google.com>
Provide a way to distinguish between a field with a zero-value
default and one with no default.
Change-Id: I4b1231de2d1bb141099cb1a415b35184dd198f93
Reviewed-on: https://go-review.googlesource.com/135255
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Implement Format methods to provide the ability to pretty-print the descriptor
in a humanly readable fashion. While this functionality is not strictly necessary
for the operation of Go protobuf, it is a useful aid for humans.
Change-Id: I88807b38b5be713867f2f2aab5a0843fc147dc35
Reviewed-on: https://go-review.googlesource.com/131255
Reviewed-by: Herbie Ong <herbie@google.com>
Useful for dealing with SourceCodeInfo location paths, which identify
entities by their index.
Change-Id: I2034fc06b14c9b29b26e356fad21e106f63fbd14
Reviewed-on: https://go-review.googlesource.com/134115
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
protoc leaves FileDescriptorProto.Syntax unset when the syntax is
"proto2".
Change-Id: Id1370145fc9c5c67344f5a998d118fd0f9f65f24
Reviewed-on: https://go-review.googlesource.com/133636
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Implement NewFileFromDescriptorProto, which constructs a
protoreflect.FileDescriptor from a provided descriptor.FileDescriptorProto.
Some other minor changes:
* Allow calling Find and Range methods on nil *protoregistry.Files to match
the behavior of maps where index operations are permitted, but store panics.
* Switch protoregistry test to be protoregistry_test to avoid cyclic dependency.
Change-Id: I5536901ef5096014a3421e63bc4a9dfcad335ea4
Reviewed-on: https://go-review.googlesource.com/132455
Reviewed-by: Damien Neil <dneil@google.com>
The prototype package provides constructors to create protobuf types that
implement the interfaces defined in the protoreflect package.
High-level API:
func NewFile(t *File) (protoreflect.FileDescriptor, error)
type File struct{ ... }
type Message struct{ ... }
type Field struct{ ... }
type Oneof struct{ ... }
type Enum struct{ ... }
type EnumValue struct{ ... }
type Extension struct{ ... }
type Service struct{ ... }
type Method struct{ ... }
func NewEnum(t *StandaloneEnum) (protoreflect.EnumDescriptor, error)
func NewMessage(t *StandaloneMessage) (protoreflect.MessageDescriptor, error)
func NewExtension(t *StandaloneExtension) (protoreflect.ExtensionDescriptor, error)
type StandaloneEnum struct{ ... }
type StandaloneMessage struct{ ... }
type StandaloneExtension struct{ ... }
func PlaceholderFile(path string, pkg protoreflect.FullName) protoreflect.FileDescriptor
func PlaceholderEnum(name protoreflect.FullName) protoreflect.EnumDescriptor
func PlaceholderMessage(name protoreflect.FullName) protoreflect.MessageDescriptor
This CL is missing some features that are to be added later:
* The stringer methods are not implemented, providing no way to print the
descriptors in a humanly readable manner.
* There is no support for proto options or retrieving the raw descriptor.
* There are constructors for Go specific types (e.g., protoreflect.MessageType).
We drop go1.9 support since we use strings.Builder.
We switch to go.11rc1 to obtain some bug fixes for modules.
Change-Id: Ieac9a2530afc81e5a5bb9ab5816804372f652b18
Reviewed-on: https://go-review.googlesource.com/129057
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Herbie Ong <herbie@google.com>
