Skip to content
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

Use decision trees for code generation on the js target #4382

Draft
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

giacomocavalieri
Copy link
Member

@giacomocavalieri giacomocavalieri commented Mar 22, 2025

This PR closes #3969 and closes #4221

This is still a WIP as I haven't taken care of bit array patterns yet, but it's ready for everything else if anyone fancies giving this a look in the meantime.

What's missing:

  • Use the decision tree for cases
  • Reuse the decision tree for let restructuring and let assert
  • Support bit arrays in the decision tree

Ok(SizedBitArraySegmentDetails { size, size_value })
}

pub(crate) fn guard(&mut self, guard: &'a TypedClauseGuard) -> Output<'a> {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the code here up to line ~1900 is basically moved as-is from the pattern module where it was previously

@lpil
Copy link
Member

lpil commented Mar 22, 2025

Please give PRs titles, just a number means folks have to look them up to know what this is

@giacomocavalieri
Copy link
Member Author

Oops my mistake!

@giacomocavalieri giacomocavalieri changed the title Fix 3969 Use decision trees for code generation on the js target Mar 23, 2025
The decision tree would have two different kinds of switches,
implementing code generation I went over this code again and realised we
could represent it using a single variant for both infinite and
exhaustive switches: at the end of the day the both still need a
"fallback" branch that will match no matter what. So I thought it would
make more sense to reconcile the two things in a single variant.
With this change code generation for pattern variables is smarter and
avoids doing lots of repeated work always recomputing the value of a
pattern variable. Instead, a pattern variable is now bound in scope as
soon as a check needs it.
I think a regular match is easier to read than the `!matches!(...)`
macro
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants