This repository was archived by the owner on Apr 25, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 25, 2025. It is now read-only.
rtt implied by ref.func #110
Description
What rtt is implied when allocating a function with ref.func? E.g., how does the following code work?
(type $bar_type ...)
(function $bar (type $bar_type) ... )
(function $foo (type ...) (local funcref) (
(local.set 0 (ref.func $bar))
(ref.test (local.get 0) (rtt.canon $bar_type)))
Activity
rossberg commentedon Aug 5, 2020
Ah, it's supposed to be the canonical RTT for the function's type, i.e., the test should succeed. I added the missing bullet.
jakobkummerow commentedon Aug 5, 2020
Just to clarify: IIUC, that means that using
rtt.subwith function RTTs is legal but useless, as any custom sub-RTTs created that way can't be used to create any references, because there is noref.func_with_rtt(akin tostruct.new_with_rtt).Also, this means that function references created with
ref.funccan't beref.casted from anyref to funcref, because their RTT is not a sub-RTT of the funcref RTT. (This is similar to i31ref not being downcastable from anyref to eqref.) I personally don't have any objections to this limitation, though I do wonder whether there are any real-world use cases that would find this inconvenient.RossTate commentedon Aug 13, 2020
@rossberg Your answer here contradicts the MVP document, which says that
rtt.is_funcwould be equivalent to(rtt.canon func) (ref.test). This issue should probably be reopened.[test] Fix the binary.wast test for multi-bytes table indices (#110)