`&&` can't be calculated at compile time

[maizi20]

Bug description

&& can't be calculated at compile time, but ?: can.

Steps to reproduce

input assemblyscript:

class A{
  foo!:i32
  bar!:i32
}
export const compiletime=offsetof<A>('foo')==0?offsetof<A>('bar')==4:0
export const runtime=offsetof<A>('foo')==0&&offsetof<A>('bar')==4

output wat:

(module
 (type $0 (func))
 (global $example/compiletime i32 (i32.const 1))
 (global $example/runtime (mut i32) (i32.const 0))
 (memory $0 0)
 (table $0 1 1 funcref)
 (elem $0 (i32.const 1))
 (export "compiletime" (global $example/compiletime))
 (export "runtime" (global $example/runtime))
 (export "memory" (memory $0))
 (start $~start)
 (func $start:example
  (local $0 i32)
  i32.const 0
  i32.const 0
  i32.eq
  local.tee $0
  if (result i32)
   i32.const 4
   i32.const 4
   i32.eq
  else
   local.get $0
  end
  i32.const 0
  i32.ne
  global.set $example/runtime
 )
 (func $~start
  call $start:example
 )
)

AssemblyScript version

0.27.37

[CountBleck]

One could say the root cause is that one of our optimizations for simplifying &&s is based off of whether the contextual type is bool (the problem goes away if you add : bool after export const runtime). That optimization would work if both operand types are bool, but since avoiding compiling the RHS is part of that optimization (and we don't know the expression type until compiling it), we can't exactly do that. (Note: just checking the left operand's type wouldn't work, since true && 3 should return an i32.)

Anyways, my fix for this is to precompute the left operand if possible, and then simplify the expression further if possible. PR coming shortly.