Support cppgc members and pointer arguments

[simonask]

Slightly related to #787.

It seems there's currently no way to take a Ptr<T: GarbageCollected> as an argument in an op as anything other than &T or Option<&T>.

That's fine, except it's not possible to create something equivalent to v8::cppgc::Member<T> from the &T.

Proposal:

• Introduce deno_core::cppgc::Member<T> (wrapping v8::cppgc::Member<CppGcObject<T>>), implementing Traced etc.
• Extend the op2 machinery even more with the ability to get a &deno_core::cppgc::Ptr<T> as an argument (note the reference - it has to be bound to the stack by the caller, and must be !Clone as it already is).
• Allow creating a deno_core::cppgc::Member<T> from a &deno_core::cppgc::Ptr<T>.

I tried to implement this myself, but I have to admit I get lost very quickly inside the op2 proc macro implementation, and it isn't obvious to me what the correct course of action is. There are some surprising aspects of the design that I would love to learn more about if someone wants to guide.

[bartlomieju]

There are some surprising aspects of the design that I would love to learn more about if someone wants to guide.

@simonask is there anything specific you want to learn?

[simonask]

@simonask is there anything specific you want to learn?

Is there a particular reason why the proc macro hardcodes every interface type together with some bespoke attributes (#[cppgc], #[smi], etc.), rather than using custom types indicating the behavior explicitly in the signature of the Rust function?

I'm thinking there could be reasons I'm not aware of relating to the fast-api stuff, but I'm curious.

Thanks for responding!

[littledivy]

It is possible to take Ptr<T> as an argument for ops using the #[webidl] attribute. Example:

#[webidl] pipeline: Ptr<GPURenderPipeline>

(It is part of the #[webidl] attribute because it performs a WebIDL instance check; in this case for GPURenderPipeline)

Is there a particular reason why the proc macro hardcodes every interface type together with some bespoke attributes (#[cppgc], #[smi], etc.), rather than using custom types indicating the behavior explicitly in the signature of the Rust function?

Yes, the explicit attributes are there to allow for special codegen in fast API calls and inline conversions. The README for op2 has a table that maps attribute and type combination to the expected V8 value: https://github.com/denoland/deno_core/tree/main/ops/op2#parameters

[simonask]

@littledivy Ah, thank you so much! But I guess WebIDL is kind of an orthogonal facility, or is the overlap with cppgc general enough to advise going this route for all cppgc types?

Also, I guess there is still a missing piece related to converting Ptr<GPURenderPipeline> (in the example) to something that looks like a v8::cppgc::Member if a cppgc types wants to store it internally. (I'm happy to give that part a shot, should be easy enough.)

[littledivy]

The WebIDL converter for Ptr is the same as cppgc - it just maps the error to be consistent with the web spec. Maybe it could be aliased to a more intuitive name?

Also, I guess there is still a missing piece related to converting Ptr (in the example) to something that looks like a v8::cppgc::Member if a cppgc types wants to store it internally.

Ptr<T> can be directly stored internally and be traced by GC. Does that cover your use-case?

struct A {
  inner: Ptr<B>,
}

impl GarbageCollected for A {
  fn trace(&self, visitor: &v8::cppgc::Visitor) {
    visitor.trace(&self.inner);
  }
}

[simonask]

@littledivy Ptr<T> wraps v8::cppgc::Ptr<T>, and is just a regular pointer, which is different from v8::cppgc::Member<T> (and v8::cppgc::WeakMember<T>). The latter insert write barriers, required for accurate GC.

Using Ptr<T> everywhere will not work with cppgc/Oilpan.

[simonask]

(But &Ptr<T> would be the correct way to pass function arguments, as far as I can tell. Note the reference to prevent the pointer from moving off the stack.)

I believe once denoland/rusty_v8#1802 is merged, deno_core should gain its own Member<T>, WeakMember<T>, Persistent<T>, and WeakPersistent<T> types that simply delegate to the appropriate v8::cppgc::* types, but hooking into the nice CppGcObject type safety wrapper. Let me know if you agree or disagree, I'm happy to push it through. :-)