forkphorus has its own test suite, most of which are regression tests for real bugs in a real compiler so it may be worth testing against.
forkphorus-befunge-eratosthenes and forkphorus-string-functions are probably the most meaningful new test cases; at the very least i wouldn't have needed a new test case in #300 to see changes in snapshots if they were merged
The tests also add coverage for specializations like "delete 1 of list" that somehow weren't in the suite before?
* replace Number.isNaN -> x !== x (see https://github.com/TurboWarp/scratch-vm/pull/367 for background on this though it matters less than expected)
* optimize listGet for numbers
* optimize listReplace for numbers
* optimize listDelete for first and last items
* optimize listContains / listIndexOf by hoisting work that would previously happened inside compareEqual many times
Our editor relies on the mutation for control_stop to know if there is a connection below.
Spork does not export that mutation anymore.
Instead, we will just generate the mutation to fix errors on loading.
The behavior is non-trivial as it will keep running the old thread
unti it yields.
I briefly tested putting `thread.status = 4` at the start of _restartThread
and all the old execution tests still passed, so let's just add a bit more
coverage. This was nearly regressed by f548d1b33c.
Works in command or reporter after yielding or not.
These snippets are covered by the tests:
thread.status = Thread.STATUS_DONE;
thread.status = 4; (indirectly)
sequencer.retireThread(thread);
Before this command:
- Interpreter would popStack() and continue. Inside a loop this was like JS continue, outside it was like return
- Compiler would return literal undefined and keep going.
After this commit:
Both return the error as a string and then continue as normal.
This has several benefits:
- Users can actually see the error messages
- Logical execution flow
- Consistent behavior
- Blocks aren't even supposed to return rejected promises anyways
- No vanilla blocks return rejected promises so no compatibility concerns
Supersedes https://github.com/TurboWarp/scratch-vm/pull/207
"stop this script" and "return" would previously cause all the procedure
arguments to be re-evaluated and then discarded. In vanilla Scratch the
worst case is a performance penalty, but with our custom reporters it
can cause infinite loops.
Fixes https://github.com/TurboWarp/scratch-vm/issues/201
Thomas Weber