Code-generate constraints.smithy
#2101
Labels
Comments
david-perez
added a commit
that referenced
this issue
Jan 13, 2023
Turns out we've never supported them, neither directly constrained nor with constrained members, because of a lack of tests. Yet another data point to prioritize working on code-generating `constraints.smithy` (see #2101). The implementation is simple: we just need to call the symbol provider on the member symbols instead of on the target symbols so we get `Option<T>` list members / map values if applicable, and handle the wrapper when converting between unconstrained and constrained types with help from `match` and `Option<T>::map`.
david-perez
added a commit
that referenced
this issue
Jan 17, 2023
Turns out we've never supported them, neither directly constrained nor with constrained members, because of a lack of tests. Yet another data point to prioritize working on code-generating `constraints.smithy` (see #2101). The implementation is simple: we just need to call the symbol provider on the member symbols instead of on the target symbols so we get `Option<T>` list members / map values if applicable, and handle the wrapper when converting between unconstrained and constrained types with help from `match` and `Option<T>::map`.
aws-sdk-rust-ci
pushed a commit
to awslabs/aws-sdk-rust
that referenced
this issue
Jan 26, 2023
…(#2213) Turns out we've never supported them, neither directly constrained nor with constrained members, because of a lack of tests. Yet another data point to prioritize working on code-generating `constraints.smithy` (see smithy-lang/smithy-rs#2101). The implementation is simple: we just need to call the symbol provider on the member symbols instead of on the target symbols so we get `Option<T>` list members / map values if applicable, and handle the wrapper when converting between unconstrained and constrained types with help from `match` and `Option<T>::map`.
david-perez
added a commit
that referenced
this issue
Apr 17, 2023
The issue is we're not changing the return type of the payload deserializing function to be the unconstrained type (e.g. the builder in case of an `@httpPayload`-bound structure shape) when the shape is constrained. Yet another example of why code-generating `constraints.smithy` (see #2101) is important. Closes #2583.
1 task
david-perez
added a commit
that referenced
this issue
Apr 19, 2023
…#2584) The issue is we're not changing the return type of the payload deserializing function to be the unconstrained type (e.g. the builder in case of an `@httpPayload`-bound structure shape) when the shape is constrained. Yet another example of why code-generating `constraints.smithy` (see #2101) is important. Closes #2583. ## Testing The added integration test operation fails to compile without this patch. ## Checklist <!--- If a checkbox below is not applicable, then please DELETE it rather than leaving it unchecked --> - [x] I have updated `CHANGELOG.next.toml` if I made changes to the smithy-rs codegen or runtime crates ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
unexge
pushed a commit
that referenced
this issue
Apr 24, 2023
…#2584) The issue is we're not changing the return type of the payload deserializing function to be the unconstrained type (e.g. the builder in case of an `@httpPayload`-bound structure shape) when the shape is constrained. Yet another example of why code-generating `constraints.smithy` (see #2101) is important. Closes #2583. ## Testing The added integration test operation fails to compile without this patch. ## Checklist <!--- If a checkbox below is not applicable, then please DELETE it rather than leaving it unchecked --> - [x] I have updated `CHANGELOG.next.toml` if I made changes to the smithy-rs codegen or runtime crates ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
rcoh
pushed a commit
that referenced
this issue
Apr 24, 2023
…#2584) The issue is we're not changing the return type of the payload deserializing function to be the unconstrained type (e.g. the builder in case of an `@httpPayload`-bound structure shape) when the shape is constrained. Yet another example of why code-generating `constraints.smithy` (see #2101) is important. Closes #2583. ## Testing The added integration test operation fails to compile without this patch. ## Checklist <!--- If a checkbox below is not applicable, then please DELETE it rather than leaving it unchecked --> - [x] I have updated `CHANGELOG.next.toml` if I made changes to the smithy-rs codegen or runtime crates ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
|
To inspect the code-generated models, we can use SmithyIdlModelSerializer. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
constraints.smithyis the Smithy model file we've been using to test our implementation of constraint traits. This model is handwritten.The file is growing bigger as time goes on and is becoming increasingly difficult for implementers to remember to test all possible (shape, constraint trait) combinations, as well as constrained shapes bound to the different parts of the HTTP message. Not to mention that some of the code paths we exercise are different depending on whether shapes are transitively constrained vs directly but not transitively constrained.
A Kotlin unit test that built this model by a more orderly exploration of the possible combinations would get as a long way. It would also serve as a stepping stone for more general fuzz-testing of Smithy models.
The text was updated successfully, but these errors were encountered: