[interpreter] Fix registry to be per-thread #219
Conversation
|
None of the tests are really able to use |
|
I think it was adopted by relaxed SIMD tests, so I don't want to lose its correct integration with the threading implementation. |
| @@ -606,8 +628,8 @@ let of_command mods cmd = | |||
| of_assertion' mods act "run" [] None ^ "\n" | |||
| | Assertion ass -> | |||
| of_assertion mods ass ^ "\n" | |||
| | Thread _ -> failwith "JS translation of Thread is NYI" | |||
| | Wait _ -> failwith "JS translation of Wait is NYI" | |||
| | Thread _ -> "" (* TODO: failwith "JS translation of Thread is NYI" *) | |||
There was a problem hiding this comment.
Sorry to have been slow to iterate on this PR. Is this behaviour preferable to having the failwith behaviour? My understanding is that this effectively causes garbled JS tests to be silently spat out instead of the translation explicitly failing.
There was a problem hiding this comment.
The practical problem is that as is, this makes the test runner fail, which also breaks CI. The conceptual problem is that the current assumption is that every core test can be converted to JS. If we want to exempt some tests, we'll need additional infrastructure for that. But what would that imply for the role of the test suite?
Is there truly no way to transform the thread construct to JS faithfully?
There was a problem hiding this comment.
There is - it would have to be a follow-up PR though. I'm just trying to clarify if generating garbled tests would be a preferable behaviour in the meantime.
There was a problem hiding this comment.
Could we at least turn the thread and wait constructs into some kind of dynamic "assert false" instead?
EDIT: maybe something like "assert_malformed <obviously malformed module>" with a comment that this is caused by a NYI construct?
There was a problem hiding this comment.
Ah, I see. The idea of opening an issue for it was to do it separately. Adding a "correct" temporary work-around probably is more work than is worthwhile.
There was a problem hiding this comment.
(The thread construct is in a completely different category than the arguments of assertions, so we cannot simply wrap it into one.)
Also:
thread.wasttest to check thread scripting featureseitherpatterns from main that got lost on upstream-rebuildAlso, I noticed that the JS translation still can't handle the
threadfeature of test scripts. I opened #218.