Skip to content
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

Merged
merged 4 commits into from
Feb 10, 2021
Merged

infer: update resolver when descending into block #7627

merged 4 commits into from
Feb 10, 2021

Conversation

jonas-schievink
Copy link
Contributor

No description provided.

enum Either { A(bool), B }
match Either::B {
//^^^^^^^^^ Missing match arm
Either::A(true | false) => (),
Copy link
Contributor Author

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

Copy link
Member

@lnicola lnicola Feb 10, 2021

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?

} else {
ty
Expr::Block { statements, tail, label, id: _ } => {
self.resolver = resolver_for_expr(self.db.upcast(), self.owner, tgt_expr);
Copy link
Member

@lnicola lnicola Feb 10, 2021

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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?

Copy link
Member

@lnicola lnicola Feb 10, 2021

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)

Copy link
Member

@flodiebold flodiebold left a 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.

@jonas-schievink
Copy link
Contributor Author

bors r+

@bors
Copy link
Contributor

bors bot commented Feb 10, 2021

@bors bors bot merged commit 7ec0343 into rust-lang:master Feb 10, 2021
@jonas-schievink jonas-schievink deleted the infer-resolver branch February 10, 2021 16:14
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