Based on CM/#647, there are already traps for sync {stream,future}.{read,write} if the stream/future is already in a waitable sets, but this PR also added traps for {stream,future}.cancel-{read,write} and subtask.cancel which seem to be necessary for the same reason. test/async/trap-if-sync-and-waitable-set.wast I believe tests this (failing when it hits an unreachable instead of the intended trap).
Based on CM/#647, there are already traps for sync {stream,future}.{read,write} if the stream/future is already in a waitable sets, but this PR also added traps for {stream,future}.cancel-{read,write} and subtask.cancel which seem to be necessary for the same reason.
test/async/trap-if-sync-and-waitable-set.wastI believe tests this (failing when it hits anunreachableinstead of the intended trap).