-
Notifications
You must be signed in to change notification settings - Fork 102
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
fix tc step types #1333
fix tc step types #1333
Conversation
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'd like to see a regression that addresses nested defpacts in here.
8d22edf
to
bfd3f1c
Compare
This PR concentrates solely on ensuring that each step's result type is consistent with the overall defpact type. While Stuart's nested defpact example remains a separate challenge, it is regarded as an independent issue and will be addressed in a future PR. This current update is dedicated to aligning step result types with the defpact's defined type. |
@@ -60,7 +60,7 @@ | |||
|
|||
(defpact test-pact-guards (id:string) | |||
(step (step1 id)) | |||
(step (step2 (read-msg "id")))) | |||
(step (let ((s2 (step2 (read-msg "id")))) "step2"))) |
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.
What does this binding do, and how is it extending the test? Is this suggesting that the return type of test-pact-guards
should be :string
?
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.
step
has return type string
, with this change, we enforce that all steps have the same return type. Hence, the change will return the "step2"
string. This is a fix to a pre-existing test (on caps).
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.
Could you please add some comments to the test describing what's going on here and what exactly is being tested by these odd constructions? (Namely, binding to a name that is never used). Everything else looks good!
This PR enhances the typechecking for defpacts by ensuring consistency in return types across all steps. Previously, varying return types were permissible for each step. This update mandates that the return type for all steps aligns with the defpact's defined result type.
PR checklist:
cabal run tests
. If they pass locally, docs are generated.pact -t
), make sure pact-lsp is in sync.Additionally, please justify why you should or should not do the following: