-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
infer: update resolver when descending into block #7627
Conversation
enum Either { A(bool), B } | ||
match Either::B { | ||
//^^^^^^^^^ Missing match arm | ||
Either::A(true | false) => (), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this is what this test intends to check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it checks that there's a "missing match arm" diagnostic because Either::B
isn't handled. But the previous comment was indeed a bit strange. Is it actually working now?
crates/hir_ty/src/infer/expr.rs
Outdated
} else { | ||
ty | ||
Expr::Block { statements, tail, label, id: _ } => { | ||
self.resolver = resolver_for_expr(self.db.upcast(), self.owner, tgt_expr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we push directly a new scope onto the Resolver
, then pop it at the end of the block, so we reuse it?
This feels a bit iffy -- we replace it, but keep using the new one even after the end of the block. Can't that lead to problems?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, yeah, I meant to swap the old one back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we push directly a new scope onto the
Resolver
, then pop it at the end of the block, so we reuse it?
We can do that, but that sort of feels like mixing concerns. I think type inference shouldn't really know about name resolution scoping rules.
Perhaps a nicer solution would be to have an HIR body visitor that gives you the correct Resolver
for every expression?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe. Or at least an API like self.resolver = resolver_for_expr(self.db.upcast(), self.owner, tgt_expr, self.resolver); /* ... */ self.resolver.pop();
?
(I'm pretty sure that won't work because of the borrow checker, but you know what I mean)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was surprisingly simple. Some more tests would be nice, e.g. more nested blocks, and bringing traits into scope locally. Apart from that LGTM.
bors r+ |
No description provided.