-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement the waiter matcher generator #3571
Conversation
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good, couple questions.
...mazon/smithy/rust/codegen/client/smithy/generators/waiters/RustWaiterMatcherGeneratorTest.kt
Show resolved
Hide resolved
"ProvideErrorMetadata" to RuntimeType.provideErrorMetadataTrait(runtimeConfig), | ||
) | ||
return RuntimeType.forInlineFun(fnName, module) { | ||
rustBlockTemplate("pub(crate) fn $fnName(_input: &#{Input}, _result: &#{Result}<#{Output}, #{Error}>) -> bool", *scope) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: So we're generating functions like pub(crate) fn match_test_operation_1555d9862d8934ff9(...)
, can we generate any kind of provenance doc comment that ties it to the model (to aid in debugging/traceability)?
In Kotlin these matcher functions are generated inline where they are used so they don't need an identifier. I think it's fine to generate them this way but I am wondering more generally what is the design for how these matches will be consumed? What will a generated waiter look like? How will these matchers be tied to an acceptor and retry strategy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add a comment above the function with the matcher json, at the very least. I imagine it will be pretty easy to identify them if you're going from the direction of waiter impl -> matcher. The acceptor/retry strategy will be calling these functions directly.
A new generated diff is ready to view.
A new doc preview is ready to view. |
...re/amazon/smithy/rust/codegen/client/smithy/generators/waiters/RustWaiterMatcherGenerator.kt
Outdated
Show resolved
Hide resolved
Co-authored-by: ysaito1001 <[email protected]>
A new generated diff is ready to view.
A new doc preview is ready to view. |
This PR implements Smithy waiter matcher union codegen. ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._ --------- Co-authored-by: ysaito1001 <[email protected]>
This PR implements Smithy waiter matcher union codegen.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.