[Do not merge] WIP: Accept typed array arguments in codegen

[Xanewok]

Preliminary work for #5014.

Sorry for a long period of inactivity on the issue. I'd like to return to working on it, however this is more of an exploratory work and approach, rather that something I'm focused on landing.

Basically the changes are limited to generating correct conversion codegen using typedarray types from rust-mozjs, for function arguments.

I believe I need more guidance on how to implement the WebIDL typed array bindings in a more complete/correct way.
First of all, these changes do not support typedef (ArrayBufferView or ArrayBuffer) BufferSource; (or any other union for that matter).

I believe that to use them inside regular union bindings code, this will more complete approach wrt rooting and possibly being stored on heap. Currently TypedArray types are only allowed on stack, since they internally hold a stack root guard. Is it possible and if so, how should such a type be stored on heap (in unions?)? Using RootedTraceableBox?

Secondly, this is the first argument that requires an outer stack root for the argument conversion. Should I add a TypedArray::from_unrooted (similar to TypedArray::from) that returns an unrooted 'converted' value, which is only rooted later at the call time, removing the need for newly-added needsRootingInto param in codegen?

@jdm @KiChjang what do you think about this?

---

For context, this is the generated code for void passTypedArray(Int8Array arg);:

// (...)
let mut arg_root = Rooted::new_unrooted();
let arg0: typedarray::Int8Array = if args.get(0).get().is_object() {
    match typedarray::Int8Array::from(cx, &mut arg_root,
        args.get(0).get().to_object()) {
        Ok(val) => val,
        Err(()) => {
            throw_type_error(cx, "value is not a typed array.");
            return false;

        }
    }

} else {
    throw_type_error(cx, "Value is not an object.");
    return false;

};
let result: () = this.PassTypedArray(arg0);
// (...)

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• These changes fix #__ (github issue number if applicable).

• There are tests for these changes OR
• These changes do not require tests because _____

---

This change is 

[highfive]

Heads up! This PR modifies the following files:

• @asajeffrey: components/script/dom/bindings/codegen/CodegenRust.py, components/script/dom/testbinding.rs, components/script/dom/webidls/TestBinding.webidl
• @fitzgen: components/script/dom/bindings/codegen/CodegenRust.py, components/script/dom/testbinding.rs, components/script/dom/webidls/TestBinding.webidl
• @KiChjang: components/script/dom/bindings/codegen/CodegenRust.py, components/script/dom/testbinding.rs, components/script/dom/webidls/TestBinding.webidl

[Xanewok]

This is really for typed arrays, whereas isSpiderMonkeyInterface() also returns true for a ReadableStream type - should I explicitly handle only typed arrays here for now?

[nox]

It would be better to only handle typed arrays here indeed.

[nox]

What is this new argument for? It seems weird to me that it is either "arg_root" or False.

[Xanewok]

The current typed array conversion API requires an existing stack root, so I wanted to also pass the name of stack root here or False if it's not needed.

In general I don't feel too good about it, since it's only used with argument conversion code and the arg_root name is duplicated anyway.

This seemed like a general mechanism that could be supported (e.g. union member conversions use a stack root before the conversion), but I think we can avoid introducing this by attempting the conversion on unrooted object and only root before the call (like with custom auto rooter), but this'd warrant changes to typed arrays API in rust-mozjs.

Should I do that?

[nox]

Why would this be False here?

[Xanewok]

I don't think it should. To be quite frank, I blindly copy-pasted the checking logic from type_needs_tracing to be safe 😢

[nox]

Please assert that t.isType() is True instead and unconditionally return t.isSpiderMonkeyInterface().

[Xanewok]

Will do!

[nox]

It would be better to only handle typed arrays here indeed.

[nox]

Why is this not just reusing isAutoRooted, which AFAIK is initialised from a call to type_needs_auto_root?

[Xanewok]

To briefly summarize from my other comment, the current typed array conversion itself requires prior stack root, whereas argument conversions with isAutoRooted only roots the type after the conversion - to avoid this, it'd need adding unrooted object typed array conversion API and/or supporting rooting those with CustomAutoRooter

[nox]

@bors-servo try

[bors-servo]

⌛ Trying commit e4f5980 with merge 40a9a95...

[bors-servo]

☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css1, mac-rel-css2, mac-rel-wpt1, mac-rel-wpt2, mac-rel-wpt3, mac-rel-wpt4, windows-msvc-dev
State: approved= try=True

[Xanewok]

Just to leave few notes regarding future direction, mainly being supported in unions:

What SpiderMonkey does is:

1. TypedArray wrappers hold a bare JSObject* and are traced using CustomAutoRooter
2. Owning unions (e.g. BufferSource) with them contain raw values of these types and are when traced, the inner objects are traced by appropriate CustomAutoRooter trace logic

From the conversation at #jsapi irc channel, Gecko only supports unions on stack and so that's why it's okay here.

However the moment we have an object in nursery that is not traced in a nursery gc (e.g. stored inside some tenured object, but not stack-rooted for nursery gc), then we'd need to use Heap<*mut JSObject>. @jdm as I understand it's to allow moving the underlying object around and promoting it from nursery to tenured heap?

Since codegen generates union types that are not limited to stack lifetime, we'd need to somehow support them being stored with Heap-wrapped storage.

How should it be done?

• By making TypedArrays also generic over storage type, being *mut JSObject or Heap<*mut JSObject> (also removing internal stack root guard and allowing it to be used in both scenarios)?
• Generating two union variants, either for stack-only or heap-only usage? (seems like a lot of work for uncertain benefits)

[jdm]

I wonder how difficult it would be to move to a model where the generated unions are only valid for stack usage like Gecko? That's probably outside the scope of your work, so I would go with the first option and make typed array generic over the storage type.

[Xanewok]

Closing in favor of #20267.