gRPC client service info #771
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It has almost zero impact on performance in practice, and permits this code to keep working with Go 1.4. Fixes golang#146.
Signed-off-by: David Symonds <[email protected]>
Clarify the unsupported nature of this interface in the README. Fixes golang#147.
Signed-off-by: David Symonds <[email protected]>
Like App Engine, GopherJS does not support unsafe. This change adds a 'js' build tag (set by GopherJS) alongside the existing 'appengine' tags. Fixes golang#154.
…required field. Signed-off-by: David Symonds <[email protected]>
Enums used in maps is still broken, but commented-out test data is now there, together with TODOs. Fixes golang#164.
…ion. See grpc/grpc-go#642 for the corresponding grpc-go change. Signed-off-by: David Symonds <[email protected]>
Signed-off-by: David Symonds <[email protected]>
Unmarshaling Any is a TODO. Fixes golang#170.
Methods that manipulate protos with extensions will now take proto.Message instead of the internal extendableProto interface. A ClearExtensions method is added to clear all extensions on protos.
While this check could be done before marshalling, it shouldn't occur frequently and thus would slow down proto encoding on average.
Turn generated message struct field XXX_Extensions map[int32]Extension into an embedded proto.InternalExtensions struct InternalExtensions is a struct without any exported fields and methods. This effectively makes the representation of the extension map private. The proto package can access InternalExtensions by checking that the generated struct has the method 'extmap() proto.InternalExtensions'. Also lock accesses to the extension map. This change bumps the Go protobuf generated code version number. Any .pb.go files generated with this version of the proto package or later will require this version or later of the proto package to compile.
When the new V2 generated extension format was introduced, we mistakenly dropped support for comparing V1 generated extensions for equality. Add that back.
This is meant to fix golang#188. There are no tests because we don't guarantee that we're going to maintain this behavior in the future. Fixes golang#188
Otherwise invalid JSON can be produced.
Regenerated .pb.go files
Bump support package version number from 2 to 3.
Add tests for merging a map field. When src contains a duplicate key, its value message replaces (not merges with) the value message in dst.
// GetAllExtensionDescs returns a slice of all the descriptors // extensions present in pb. // // If an extension is not registered, a descriptor with only the // 'field' value set will // // be returned instead of a full descriptor. // // The returned slice is not guaranteed to be in any given order. // func GetAllExtensionDescs(pb Message) (extensions []*ExtensionDesc, // err error)
A test depends on the new 'Cute' field.
I added a new Unmarshaler type for symmetry with Marshaler.
Avoid interleaving plugin output with the rest of the generated code. No functional change, but simplifies keeping the v1 and v2 generator output identical.
Split imports into standard library and third-party imports. Decide between the two based on the presence of a ".", which is the same heuristic used by goimports. Allow plugins to register packages to import, so gRPC imports don't sit awkwardly in a separate import () block.
Keep plugin imports and non-plugin imports in the same section, but don't try to split stdlib and non-stdlib imports into different sections. Consistent with using astutil to insert all imports from a blank slate.
Don't generate identifiers that conflict with predeclared identifiers, prepend with "_" instead. Signed-off-by: Arjun Sreedharan <[email protected]>
…names (golang#724) Permit creating a generated package named e.g., "string". Apply disambiguation to prevent creating a local import name that conflicts with predefined identifiers; importing package "string" will be done as: import string1 "string"
Avoid turning comments like "//////" into "// ////".
Parse floating-point default values and format them with fmt.Sprint. Eliminates a minor point of inconsistency with the v2 generator.
Convert all the import_public protos to proto2 to allow testing more features. Add usage of groups, extensions, and default values.
Groups were being excluded from the set of messages we generate forwarding declarations for. Include them.
Test the following case: File 1 defines a symbol S. File 2 publicly imports file 1. File 3 imports file 2 and uses S. All files in different Go packages: P1, P2, P3. Note that the .pb.go for file 3 could import P1 or P2, since the symbol is defined in both.
Consider this case: File 1 defines M. File 2 publicly imports file 1. File 3 imports file 2, and references M. Each file is in a different Go package: P1, P2, P3. Should the generated Go code for file 3 reference P1.M, or P2.M? The two should be equivalent, since file 2 will contain a forwarding declaration such as "type M = P1.M". Historically, we've gone with the latter (P2.M). This does make sense: A generated file only imports the packages of the files that it directly imports. However, this does have some mildly surprising effects. If File 3 imports files 2a and 2b, each of which publicly imports file 1, we need to arbitrarily pick one of P2a.M or P2b.M. (Admittedly an obscure case.) Simplify the generator a little bit (and, more importantly, make it consistent with the v2 generator) and change to referencing public imports directly.
Despite the naming, these are "internal-only" functions that are intended to
only be called from generated code for MessageSets.
Furthermore, MessageSets are themselves a deprecated feature from proto1 days,
such that descriptor.proto even warns against their use since the initial
open-source release of protocol buffers in 2008. Within Google,
there are no direct usages of these functions, and all existing
usages of MessageSets go through the new table-driven implementation.
In addition to deprecating the {Unm,M}arshalMessageSet{JSON} top-level functions,
also modify the generator to stop emitting MarshalJSON and UnmarshalJSON methods
for messages sets. The UnmarshalJSON method is not implemented and the
MarshalJSON method does not seem to be called anywhere in Google (verified by
making the method panic and doing a global test). The jsonpb package continues
to work with MessageSets.
I should note that when the table-driven implementation was open sourced
in late 2017 (see 8cc9e46), it accidentally
removed generation of the Marshal and Unmarshal method. However, no one seemed
to have noticed that those methods were no longer generated.
…g#746) The current API represents scalar extension fields as *T and repeated extension fields as []T. However, this is not an accurate reflection of the protobuf data model. For scalars, pointers are usually used to represent nullability. However, in the case of extension scalars, there is no need to do so since presence information is captured by checking whether the field is in the extension map. For this reason, presence on extension scalars is not determined by checking whether the returned pointer is nil, but whether HasExtension reports true. For repeated fields, using []T means that the returned value is only a partially mutable value. You can swap out elements, but you cannot change the length of the original field value. On the other hand, the reflective API provides methods on repeated field values that permit operations that do change the length. Thus, using *[]T is a closer match to the protobuf data model. This CL changes the implementation of extension fields to always store T for scalars, and *[]T for repeated fields. However, for backwards compatibility, the API continues to provide *T and []T. In theory, this could break anyone that relies on memory aliasing for *T. However, this is unlikely since: * use of extensions themselves are relatively rare * if extensions are used, it is recommended practice to use a message as the field extension and not a scalar * relying on memory aliasing is generally not a good idiom to follow. The expected pattern is to call SetExtension to make it explicit that a mutation is happening on the message. * analysis within Google demonstrates that no one is relying on this behavior.
Update all proto files that is obtained from the upstream repository to v3.6.1.
…olang#760) The marshaler, unmarshaler, and sizer functions are unused ever since the underlying implementation was switched to be table-driven. Change the function to only return the wrapper structs. This change: * enables generated protos to drop dependencies on certain proto types * reduces the size of generated protos * simplifies the implementation of oneofs in protoc-gen-go Updates golang#708
piotrkowalczuk
force-pushed
the
feature/client-service-info
branch
from
a8ffd03
to
0c09b40
Compare
|
\cc @dfawley The v2 API is aiming to make protobuf reflection a first-class feature. This PR adds overlap with that work and I'm hesitant to see this be merged. |
|
I would also prefer to accomplish this with support in the primary proto package/generator, and not in the grpc codegen. (See also this related issue: grpc/grpc-go#1914) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces new function in gRPC specific generated code
ClientServiceInfo. It accepts aninterface{}and returns agrpc.ServiceInfo.The rationale for this feature is to expose more detailed information about the service on the client side. It can be used, for example, to preallocate metrics — something already possible on a server side.