Skip to content

Conversation

@kripken
Copy link
Member

@kripken kripken commented Nov 10, 2023

This implements an idea I mentioned in the past, to extract the subtyping discovery
code out of Unsubtyping so it could be reused elsewhere. Example possible uses:
the validator could use to remove a lot of code, and also a future PR of mine will
need it. Separately from those, I think this is a nice refactoring as it makes Unsubtyping
much smaller.

This just moves the code out and adds some C++ template elbow grease as needed.

@kripken kripken requested a review from tlively November 10, 2023 20:35
@kripken kripken changed the base branch from main to alt.1 November 10, 2023 20:36
Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

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

This LGTM % some small comments. It would be very exciting if this let us simplify the validator.

Comment on lines 56 to 57
// example,
// in a CallIndirect.
Copy link
Member

Choose a reason for hiding this comment

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

Looks like the formatting could be more consistent here.

Comment on lines +60 to +61
// * noteCast(Expression, Expression) - An expression's type is cast to
// another, for example, in RefCast.
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps I'll find out below, but what is the benefit of this over just extracting the type of the cast expression and using noteCast(Expression, Type) in this case?

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 PR tries to keep the info as "high-level" as possible, that is, not to lose information. We might want the extra information here to say something about the expression that fails to validate, if we use this in the validator some day (though, if we have the cast anyhow, we can do cast->value).

// The parent must also inherit from ControlFlowWalker (for findBreakTarget).
//

template<typename Parent>
Copy link
Member

Choose a reason for hiding this comment

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

Do we have any other cases where we take a parent as a parameter instead of a subclass as a parameter?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, maybe "Parent" is a confusing name here, yeah. It's the same as the usual pattern.

Base automatically changed from alt.1 to main November 14, 2023 01:01
@tlively
Copy link
Member

tlively commented Nov 14, 2023

I think that if we wanted to use this in the validator, we would want to note the "subtyping" for non-ref values as well.

@kripken
Copy link
Member Author

kripken commented Nov 14, 2023

Good point, yeah - maybe when we get there, this could be renamed to ReferenceSubtypingDiscoverer, and we'd have a subclass that is a general one that adds non-refs?

@kripken kripken merged commit 1fcb57e into main Nov 16, 2023
@kripken kripken deleted the alt.2 branch November 16, 2023 00:04
radekdoulik pushed a commit to dotnet/binaryen that referenced this pull request Jul 12, 2024
This implements an idea I mentioned in the past, to extract the subtyping discovery
code out of Unsubtyping so it could be reused elsewhere. Example possible uses:
the validator could use to remove a lot of code, and also a future PR of mine will
need it. Separately from those, I think this is a nice refactoring as it makes Unsubtyping
much smaller.

This just moves the code out and adds some C++ template elbow grease as needed.
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