Exporting a Rust function with an argument named wasm can sometimes clash with internal wasm JavaScript var

[WilliamVenner]

Describe the Bug

If you export a Rust function with an argument named wasm, it will in some cases throw an error when called from JavaScript.

Steps to Reproduce

I exported a function with this signature:

#[wasm_bindgen]
pub fn wasm2wat(wasm: &[u8]) -> Result<String, JsValue>

It generates this on the JavaScript side:

/**
* @param {Uint8Array} wasm
* @returns {string}
*/
function wasm2wat(wasm) {
    let deferred3_0;
    let deferred3_1;
    try {
        const retptr = wasm.__wbindgen_add_to_stack_pointer(-16);
        const ptr0 = passArray8ToWasm0(wasm, wasm.__wbindgen_malloc);
        const len0 = WASM_VECTOR_LEN;
        wasm.wasm2wat(retptr, ptr0, len0);
        var r0 = getInt32Memory0()[retptr / 4 + 0];
        var r1 = getInt32Memory0()[retptr / 4 + 1];
        var r2 = getInt32Memory0()[retptr / 4 + 2];
        var r3 = getInt32Memory0()[retptr / 4 + 3];
        var ptr2 = r0;
        var len2 = r1;
        if (r3) {
            ptr2 = 0; len2 = 0;
            throw takeObject(r2);
        }
        deferred3_0 = ptr2;
        deferred3_1 = len2;
        return getStringFromWasm0(ptr2, len2);
    } finally {
        wasm.__wbindgen_add_to_stack_pointer(16);
        wasm.__wbindgen_free(deferred3_0, deferred3_1, 1);
    }
}

In the finally block, it tries to refer to an internal wasm variable but this fails due to the name of the argument.

Expected Behavior

The #[wasm_bindgen] macro should probably throw a compiler error, or more naturally should internally rename the function argument on the JS side to resolve the clash.

Actual Behavior

It compiles with no errors but fails at runtime.

[daxpedda]

I think it would be better to rename the internal wasm variable to __wbinden_wasm or something like that.
Not entirely sure what this would break though.

[hamza1311]

I think it would be better to rename the internal wasm variable to __wbinden_wasm or something like that.
Not entirely sure what this would break though.

That shouldn't break anything since that variable is private to the module