Skip to content
This repository was archived by the owner on Jan 9, 2026. It is now read-only.

fix tc step types#1333

Merged
jmcardon merged 1 commit intomasterfrom
rsoeldner/fix-step-tc
Feb 13, 2024
Merged

fix tc step types#1333
jmcardon merged 1 commit intomasterfrom
rsoeldner/fix-step-tc

Conversation

@rsoeldner
Copy link
Copy Markdown
Member

@rsoeldner rsoeldner commented Jan 18, 2024

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:

  • Test coverage for the proposed changes
  • PR description contains example output from repl interaction or a snippet from unit test output
  • Documentation has been updated if new natives or FV properties have been added. To generate new documentation, issue cabal run tests. If they pass locally, docs are generated.
  • Any changes that could be relevant to users have been recorded in the changelog
  • In case of changes to the Pact trace output (pact -t), make sure pact-lsp is in sync.

Additionally, please justify why you should or should not do the following:

  • Confirm replay/back compat
  • Benchmark regressions
  • (For Kadena engineers) Run integration-tests against a Chainweb built with this version of Pact

@rsoeldner rsoeldner marked this pull request as draft January 18, 2024 15:08
@rsoeldner rsoeldner marked this pull request as ready for review January 18, 2024 17:31
Copy link
Copy Markdown
Contributor

@emilypi emilypi left a 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.

@rsoeldner rsoeldner force-pushed the rsoeldner/fix-step-tc branch from 8d22edf to bfd3f1c Compare January 19, 2024 07:35
@rsoeldner
Copy link
Copy Markdown
Member Author

I'd like to see a regression that addresses nested defpacts in here.

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.

(defpact test-pact-guards (id:string)
(step (step1 id))
(step (step2 (read-msg "id"))))
(step (let ((s2 (step2 (read-msg "id")))) "step2")))
Copy link
Copy Markdown
Contributor

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?

Copy link
Copy Markdown
Member Author

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).

Copy link
Copy Markdown
Contributor

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!

@jmcardon jmcardon merged commit 45c8eca into master Feb 13, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants