Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
lizmat hmmmm in my work on ParaSeq, I'm seeing occasional test failures that can only explain by nqp::eqaddr() returning something other than 0 or 1 14:03
nvm, it's probably something else 14:05
Geth MoarVM/main: 51ca012d20 | (Patrick Böker)++ | src/core/frame.c
Reapply "Don't lose return value with LEAVE phasers"

This reverts commit d67da80f392eff0c262491c05520bbc3cdc93eb9.
2024.05 has happened. So give this another try.
20:48
patrickb Any reason not to also merge Idea: Let's distinguish `CONTROL` exceptions from `CATCH` exceptions. 20:49
That's an already well established distinction.
Given the word "conflict" means: An exception thrown within a phaser
during an unwind (a `LEAVE`) wants to unwind out of that phasers
frame.
Then I propose the following rules:
- A `CATCH` exception is in progress, a `CONTROL` exception conflicts.
-> We ignore the `CONTROL` exception and continue with the `CATCH`
exceptions unwind. 20:50
- A `CONTROL` exception is in progress, a `CONTROL` exception
conflicts. (That's what has been discussed at length in this issue.)
-> We compare the target frames of the two exception handlers. The one
unwinding more of the stack wins. If it's a tie, the later one (the
one originating from within the phaser) wins. (This behavior is
implemented in github.com/MoarVM/MoarVM/pull/1812.)
- A `CONTROL` or `CATCH` exception is in progress, a `CATCH` exception
conflicts. -> We add the exception to a list (located in the frame the
current unwind targets). After the unwind finishes and before we run
the handler, we throw all the collected exceptions. That's what
[S04](github.com/Raku/old-design-docs/bl...585-L1588)
arg! Sorry, misspaste.
Any reason not to also merge github.com/MoarVM/MoarVM/pull/1785 ?
This is what it should have been. /o\