Skip to content

Conversation

ShinWonho
Copy link
Contributor

I noticed that subtype rule for exn appears to be missing.

Screenshot 2025-03-04 at 3 57 03 PM

I have added the rule.

@ShinWonho ShinWonho changed the title Add missing subtype rule for exn [spec] Add missing subtype rule for exn Mar 4, 2025
@rossberg
Copy link
Member

rossberg commented Mar 4, 2025

Thanks, this was indeed missing from the SpecTec formulation as well. I just added it there.

However, I also noticed that the rules for noexn and noextern are vacuous this way, since there is no other ht between the top and bottom type. So these two rules need to be noexn <: exn and noextern <: extern. Could you fix that for this PR as well?

Copy link
Member

@rossberg rossberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@rossberg rossberg merged commit 9fc47e0 into WebAssembly:wasm-3.0 Mar 4, 2025
10 of 11 checks passed
@ShinWonho
Copy link
Contributor Author

I have a question.
I think the interpreter code should be changed accordingly.

(* current code *)
let rec match_heap_type c t1 t2 =
  match t1, t2 with
  ...
  | NoExnHT, t -> match_heap_type c t ExnHT
  | NoExternHT, t -> match_heap_type c t ExternHT

This code is current implementation of subtype of heap type.
And it should be fixed like below:

(* fixed code *)
let rec match_heap_type c t1 t2 =
  match t1, t2 with
  ...
  | NoExnHT, ExnHT -> true
  | NoExternHT, ExternHT -> true

Is it make sense?

@rossberg
Copy link
Member

rossberg commented Mar 4, 2025

Yes, you are right. And there should be a test for it. Can I interest you in adding that? :)

@ShinWonho
Copy link
Contributor Author

ShinWonho commented Mar 4, 2025

Sure! Actually, I'm currently working on testing subtypes. I'll create another PR for that.

@ShinWonho
Copy link
Contributor Author

I realized that subtyping between noexn and exn, as well as between noextern and extern, already exists in test/core/ref_null.wast:

(module  
  ...  
  (global $nullexn nullexnref (ref.null noexn))  
  (global $nullextern nullexternref (ref.null noextern))  
  ...  
)

For these to be valid globals, ref.null noexn and ref.null noextern must have types nullexnref and nullexternref, respectively.
This holds due to the value typing relation:

  • By null reference typing, ref.null noexn and ref.null noextern have types ref null noexn and ref null noextern.
  • By subsumption, these types become ref null exn and ref null extern.

Thus, it tests subtyping between noexn and exn, as well as between noextern and extern, within subsumption.
Screenshot 2025-03-05 at 1 24 59 PM

Would you consider adding more test cases?

P.S. I noticed that null reference typing is missing the noexn case. I will add it.
Screenshot 2025-03-05 at 1 26 17 PM

@rossberg
Copy link
Member

rossberg commented Mar 5, 2025

Ah, no, note that nullex[ter]nref is short for (ref null noex[ter]n), so these globals do not actually exercise any subtyping.

@ShinWonho
Copy link
Contributor Author

Apologies, I provided the wrong example.
Here is the correct example for testing subtype in test/core/ref_null.wast 44-46:

  (global exnref (ref.null noexn))
  (global externref (ref.null noextern))

@rossberg
Copy link
Member

rossberg commented Mar 5, 2025

Ah right, and actually, my earlier comment about the existing rules being vacuous was nonsense: they still work, by reducing the goal to reflexivity of the top type. Otherwise the interpreter would not have succeeded on these tests. :)

@ShinWonho
Copy link
Contributor Author

In that case, would updating the interpreter code be sufficient?

@rossberg
Copy link
Member

rossberg commented Mar 5, 2025

Not even that, the interpreter is alright already. We could also revert the change in the spec I asked you for, but both versions are correct.

@ShinWonho
Copy link
Contributor Author

Oh, I see. Thanks for the comments!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants