Generate conformances files containing a message are passed to the plugin #837
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
…ugin Motivation: There was some code in the codegen which checked whether the codegen request contained any services. If there were no services in the request then no code would be generated. This was fine when we generated conformance based on when request/response types of a service. Less see now. Modifications: - Remove the conditional check - Remove some related dead code - Add a couple of tests which validate that we do the right thing when we generate a file with just a service and the same for just a message. Result: Less broken codegen
MrMage
approved these changes
Jun 10, 2020
There was a problem hiding this comment.
As far as I see it, observedMessages was no longer being read from, anyway. So this PR does not actually change the codegen logic. Is that correct?
Reviewed 9 of 9 files at r1.
Reviewable status:complete! all files reviewed, all discussions resolved
glbrntt
commented
Jun 10, 2020
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjust the server components such they only support SwiftProtobuf. Once the client side has had the same treatment (and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`), support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
that referenced
this pull request
Jul 13, 2020
…rver (#886) Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: #738, #778, #801, #837, #877, #881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on grpc#886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on grpc#886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on grpc#886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
glbrntt
added a commit
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: #738, #778, #801, #837, #877, #881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on #886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation:
There was some code in the codegen which checked whether the codegen
request contained any services. If there were no services in the request
then no code would be generated. This was fine when we generated
conformance based on when request/response types of a service. Less see
now.
Modifications:
we generate a file with just a service and the same for just a
message.
Result:
Less broken codegen
This change is