-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Match statements #5485
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
Match statements #5485
Conversation
awesome, you already got the key parts |
It almost finishes codegen, the only problem faced right now is this error:
What seems to be happening is the |
When I encountered similar issue before, it was related to wrong order of value stack/block stack operations. #5275 was one of them |
Currently there is a test in |
Though I don't know well how this blocks are working, |
@coolreader18 do you have advices? |
a1586d0
to
be4df5d
Compare
The cpython implementation also has a hacky way of popping things off the stack (by repeatedly switching to blocks) and I'm not sure that's going to run without panicking anymore |
f644179
to
be4df5d
Compare
Seems like codegen almost works, it's currently getting an u32::MAX mixed in somewhere it's not supposed to be however. Debug printing:
|
Seems like all the blocks target u32::MAX as their next block. I modified them to point at the next block as their target and string together that way. |
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
45c622e
to
aa6a040
Compare
Currently the output is as follows:
for # match_test.py
v = "one"
match v:
case "one":
v = "two"
case "two":
v = "three"
case "three":
v = "one"
case _:
v = "one" |
If you'd like to investigate how stackdepth work, trying this issue probably be helpful #5154 |
I think I will try solving this by carefully checking the generated instructions |
the issue is that everything is jumping to line 0 for no reason (see line 21, line 9, and line 32 of the bytecode) |
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
Ok I rewrote some parts of it and it works for basic match statements now. @youknowone do I have to pop stuff from the stack when I'm done with it? |
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
If there are redundant stack elements for other purpose, yes, I guess so. |
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
Due to the other functions being much more complicated than expected I think we can let this PR be merged for now and I can follow up with more PRs that fix the unimplemented sections. |
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
See |
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
I agree to merge it. It compiles without panic. It is already a big progress |
64f439f
to
ed55da1
Compare
ed55da1
to
1ca706c
Compare
1ca706c
to
4beef2c
Compare
@arihant2math I removed unused nop, swap op in this merge. Please cherry-pick this commit to get it back |
This pr turns the parsed AST of a match-case statement into bytecode for the VM.
Progress:
compile_match
compile_match_inner
compile_pattern
compile_pattern_value
compile_pattern_singleton
compile_pattern_sequence
(requires instructionMATCH_SEQUENCE
instruction)compile_pattern_mapping
compile_pattern_class
compile_pattern_star
compile_pattern_as
compile_pattern_or
compile_pattern_as
first (might be done in a separate pr)Resolves: #4770