Repository navigation
&& can't be calculated at compile time #2946
Description
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')==4output 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
Activity
CountBleck commentedon Sep 7, 2025
One could say the root cause is that one of our optimizations for simplifying
&&s is based off of whether the contextual type isbool(the problem goes away if you add: boolafterexport const runtime). That optimization would work if both operand types arebool, 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, sincetrue && 3should return ani32.)Anyways, my fix for this is to precompute the left operand if possible, and then simplify the expression further if possible. PR coming shortly.
fix: simplify && and || when the LHS is constant
fix: simplify && and || when the LHS is constant