Effects: Clarify trap effect meaning, and consider infinite loops to trap due to timeout (#5039)

I think this simplifies the logic behind what we consider to trap. Before we had kind of
a hack in visitLoop that now has a more clear reasoning behind it: we consider as
trapping things that trap in all VMs all the time, or will eventually. So a single allocation
doesn't trap, but an unbounded amount can, and an infinite loop is considered to
trap as well (a timeout in a VM will be hit eventually, somehow).

This means we cannot optimize way a trivial infinite loop with no effects in it,

while (1) {}

But we can optimize it out in trapsNeverHappen mode. In any event, such a loop
is not a realistic situation; an infinite loop with some other effect in it, like a call to
an import, will not be optimized out, of course.

Also clarify some other things regarding traps and trapsNeverHappen following
recent discussions in https://github.com/emscripten-core/emscripten/issues/17732
Specifically, TNH will never be allowed to remove calls to imports.

1 files changed, 3 insertions, 0 deletions

diff --git a/test/wasm2js/br_table_to_loop.wast b/test/wasm2js/br_table_to_loop.wast
index 83d3702c2..a74d5ffe0 100644
--- a/test/wasm2js/br_table_to_loop.wast
+++ b/test/wasm2js/br_table_to_loop.wast
@@ -1,6 +1,8 @@
 (module
  (func "exp1"
   (block $block
+   ;; An infinite loop. When optimizing, wasm2js enables ignore-implicit-traps
+   ;; and so it can simplify this.
    (loop $loop
     (br_table $block $loop $block (i32.const 1))
    )
@@ -8,6 +10,7 @@
  )
  (func "exp2"
   (block $block
+   ;; A loop that never executes. This can be optimized into a nop.
    (loop $loop
     (br_table $loop $block $loop (i32.const 1))
    )