Skip to content

Conversation

@tlively
Copy link
Member

@tlively tlively commented Oct 14, 2025

This will let us enforce that the type of a ref.func is equal to the type of the referenced function, even once we introduce inexact function imports.

@kripken
Copy link
Member

kripken commented Oct 14, 2025

As discussed, I'll take a look at finishing this.

@kripken kripken self-assigned this Oct 14, 2025
@kripken kripken removed their assignment Oct 14, 2025
@kripken
Copy link
Member

kripken commented Oct 14, 2025

@tlively this builds and has main merged in, but it has test errors.

I actually am not sure how you were planning on fixing these. E.g. the test/lit/merge/func_subtyping.wat is an error on the imported type not matching the exported type, and indeed if we give these things exact types then they don't subtype.

We could give all function types inexact types for now..? Or just do the larger change as part of this one?

@tlively
Copy link
Member Author

tlively commented Oct 15, 2025

That wasm-merge error should go away if we keep checking subtyping only on the heap types for now.

@kripken
Copy link
Member

kripken commented Oct 15, 2025

I worry that might be a bit of a tightrope to walk here... may be better to fix it all in one PR. But I added that now.

@kripken kripken marked this pull request as ready for review October 15, 2025 17:21
@kripken
Copy link
Member

kripken commented Oct 15, 2025

@tlively this should be good to go

auto type = func->type;
if (func->base == "fromCharCodeArray") {
if (type != Signature({array16, i32, i32}, refExtern)) {
if (type.with(Inexact).getHeapType() !=
Copy link
Member Author

Choose a reason for hiding this comment

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

Since we treat exactness as being a property of reference types rather than heap types, the .with(Inexact) here is not doing anything. Is it there so we remember to remove it along with the .getHeapType() in the future?

Copy link
Member

Choose a reason for hiding this comment

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

Ah, I must have done this in two parts, and missed that the latter made the former redundant. Fixed.

Comment on lines 2388 to 2390
// TODO: Compare the full Type
shouldBeEqual(curr->type.getHeapType(),
func->type.getHeapType(),
Copy link
Member Author

Choose a reason for hiding this comment

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

This one

Suggested change
// TODO: Compare the full Type
shouldBeEqual(curr->type.getHeapType(),
func->type.getHeapType(),
// TODO: Compare the full Type
shouldBeEqual(curr->type,
func->type,

If this change works as intended, both sides will always be non-nullable and exact here. Once we start making some imports inexact, this will help make sure everything stays internally consistent.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, not sure why I thought this one must be deferred. Good point, it was a bug, in the fuzzer. Fixed.

kripken and others added 8 commits October 15, 2025 11:28
Co-authored-by: Thomas Lively <tlively@google.com>
Co-authored-by: Thomas Lively <tlively@google.com>
Co-authored-by: Thomas Lively <tlively@google.com>
Co-authored-by: Thomas Lively <tlively@google.com>
Co-authored-by: Thomas Lively <tlively@google.com>
@tlively
Copy link
Member Author

tlively commented Oct 15, 2025

I cannot approve this in the GitHub UI since I'm the one who originally uploaded it, but LGTM. Thanks for taking this over!

Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

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

obama giving medal to himself

@kripken
Copy link
Member

kripken commented Oct 15, 2025

A few thousand fuzzer iterations without errors, landing.

@kripken kripken merged commit d43c40d into main Oct 15, 2025
16 checks passed
@kripken kripken deleted the function-type branch October 15, 2025 19:46
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.

3 participants