Regarding argument annotations, the last sentence of section 5.1 of the spec reads:
... the third [form annotates] as type float. In the latter case, Lookup(Δ, Γ, f) must be fround.
But f's variable environment Γ does not yet exist. It is constructed during ValidateFunction(Δ, f), which necessarily occurs after the "completed" global environment Δ is constructed, and therefore after f's argument annotations are inspected (according to the procedure given in section 6.1).
This raises a deeper concern relating to JavaScript's variable hoisting semantics and float-annotated arguments (and returns), best explained by a simple example:
function M(std) {
"use asm"
var f = std.Math.fround
function g(x) {
x = f(x)
var f = 1
return f(x)
}
return g
}Without AOT compilation, M(window)(0), for example, raises an exception, but with AOT compilation, no such exception is raised. This suffices to contradict (in section 1):
the execution semantics [of asm.js] is simply that of JavaScript
Variable hoisting only causes such problems when a function f contains a local variable whose identifier is equal to that of a global variable that imports Math.fround. Otherwise, in terms of f's observational behaviour, it is immaterial whether its local variable declarations are in fact hoisted above its argument annotations. A straightforward solution follows; ValidateFunction(Δ, f) must insist that the identifier x of each local variable is such that Δ(x) ≠ imm fround.
Regarding argument annotations, the last sentence of section 5.1 of the spec reads:
But f's variable environment Γ does not yet exist. It is constructed during ValidateFunction(Δ, f), which necessarily occurs after the "completed" global environment Δ is constructed, and therefore after f's argument annotations are inspected (according to the procedure given in section 6.1).
This raises a deeper concern relating to JavaScript's variable hoisting semantics and
float-annotated arguments (and returns), best explained by a simple example:Without AOT compilation,
M(window)(0), for example, raises an exception, but with AOT compilation, no such exception is raised. This suffices to contradict (in section 1):Variable hoisting only causes such problems when a function f contains a local variable whose identifier is equal to that of a global variable that imports
Math.fround. Otherwise, in terms of f's observational behaviour, it is immaterial whether its local variable declarations are in fact hoisted above its argument annotations. A straightforward solution follows; ValidateFunction(Δ, f) must insist that the identifier x of each local variable is such that Δ(x) ≠imm fround.