-
Notifications
You must be signed in to change notification settings - Fork 0
Add value_kind for blocks to propagate types from the lambda #382
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add value_kind for blocks to propagate types from the lambda #382
Conversation
Not exactly sure about upstreaming, but it would be useful to split this PR in two, one for the upstream and one for the Flambda 2 parts. |
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've reviewed the typeopt.ml parts. I think the use of a visited set should be replaced by a fuel parameter.
@lpw25 Please could you review this again |
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.
The typeopt.ml bits look fine now.
a256c71
to
9cb0ed8
Compare
I ended up adding the dead let handling specifically in expr_builder because it uses non-optimising let introduction functions. |
9cb0ed8
to
a8826e4
Compare
2431b3c
to
d1763b5
Compare
I've made a few changes which will hopefully fix the CI, then will merge. |
This adds a code dependency between Typeopt and Lambda, which require some changes in the link order.
b4e3ffc
to
bf328a6
Compare
This is required to unbox blocks arguments of recursive continuations.
Variants are not handled.
Should the non flambda part be pushed upstream, and when ?