jameysharp requested elliottt for a review on PR #5174.
jameysharp opened PR #5174 from rule-visitor
to main
:
This shouldn't change behavior at all, but makes some rather tricky analysis available to other users besides the current IR.
<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
jameysharp updated PR #5174 from rule-visitor
to main
.
elliottt submitted PR review.
elliottt created PR review comment:
Why have the
RuleVisitor
extendPatternVisitor
but have aExprVisitor
associated type? Would it be reasonable to have aPatternVisitor
associated type here instead?Having both types be associated types would I think force the interface used in
lower_rule
to be a bit more consistent -- right now the expression sequence is returned while the pattern sequence is an in/out param.
elliottt submitted PR review.
jameysharp updated PR #5174 from rule-visitor
to main
.
jameysharp submitted PR review.
jameysharp created PR review comment:
My simplest answer is "because I needed
ExprVisitor
to be a different type fromRuleVisitor
but I didn't needPatternVisitor
to be a different type." In fact for the new IR I'm building that I want to use this in, all three types are the same, because expressions are de-duplicated acrossif-let
s and even across separate rules in the same term.That's a pretty weak justification though. There's certainly a nice symmetry argument for making both be associated types, and it could support more general usage. It also gives
RuleVisitor
s the opportunity to ignore patterns, like they currently could ignore expressions.But making
PatternVisitor
an associated type doesn't changelower_rule
at all, orRule::visit
significantly. The fundamental reason those look weird is because visiting a pattern returns nothing, while visiting an expression returns some result. I think that distinction is inherent.PatternId
s name the inside of a pattern, top-down, so aPatternVisitor
can record anything it might need as it goes.ExprId
s name the outside of an expression, bottom-up, so there's a final result that the visitor might need to do something with.It looks especially weird with the current IR because
PatternSequence::add_expr
returns ownership of an entire heap-allocatedExprSequence
. My new IR just has to return an array index there, so I think that'll be a little less confusing.Anyway, I've implemented this because the symmetry really is nice. It makes the
RuleVisitor
trait definition noisy with<Self::PatternVisitor as PatternVisitor>::PatternId
but so it goes.
jameysharp has enabled auto merge for PR #5174.
jameysharp merged PR #5174.
Last updated: Dec 23 2024 at 12:05 UTC