Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Issue 1458 #3879

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants
Contributor

catamorphism commented Oct 28, 2012

This is a pull request to implement @graydon 's suggestion, way back in #1458, of preserving parenthesization in the AST.

I have the feeling that WRT trans and typeck, there could be fewer explicit special cases for expr_paren. This has something to do with the adjustments table in the type context, and I don't entirely understand how it works. At any rate, this passes tests. Suggestions welcome.

Unfortunately, the test from #1458 still doesn't work, for apparently-separate reasons.

r? @graydon

Contributor

catamorphism commented Oct 28, 2012

Actually, now I'm wondering if it would be simpler to add a set of node-IDs-for-exprs-that-should-be-parenthesized to the type context. That would avoid the awkwardness over "if e has some property, does (e) also have that property?"

Contributor

nikomatsakis commented Oct 28, 2012

The adjustments table is created by the type checker whenever an auto-deref or auto-ref occurs (field access, method access, indexing). It indicates the location of these automatic adjustments. The interaction between an adjustment and parentheses will depend on how you modified the type checker. It seems that you are "deparenthesizing" at various places, and this is no doubt what's causing the adjustments to be stored at the subexpressions rather than the outer paren expressions.

I have to say this patch worries me slightly. In particular, I am not sure what other tables may be mis-indexed due to these changes, and it seems like this patch makes it more complex to know when the "irrelevant" parens can safely be skipped over and when they cannot. I'd feel better if the treatment of expr_paren was more uniform with other expressions (which is probably possible, given some refactoring, I don't quite know what problems you were running into that merited the introduction of each de-parenthesization).

In general, I think it'd be a good idea to construct an "overlay CFG" for the AST that we use for all of our analysis (particularly flow-based things like liveness and (hopefully someday) borrow check, but also trans). I can elaborate more in some other forum on this idea, but it would have the benefit of allowing us to include parentheses in the AST for pretty-printing, but remove them for all other purposes. We could also do other similar normalizations.

Contributor

nikomatsakis commented Oct 28, 2012

One disadvantage to both of these approaches is that they are not particularly resilient to modifications to the tree. For example, pretty-printed output from syntax extensions might not parse if it fails to insert paren nodes or entries into this map. In that regard, the current approach of having the pretty printer deduce where explicit parens are required is better. I wonder if we can simplify the syntax in any way to make this easier.

Contributor

catamorphism commented Oct 29, 2012

I'm working on an improved version of this patch.

Contributor

catamorphism commented Oct 30, 2012

I just uploaded an improved version that doesn't "deparenthesize". The only thing that's still a little suspicious is the expr_paren case in check::check_expr_with_unifier. I'm happy to explain that if necessary.

This passes tests locally and I just pushed to try.

Contributor

catamorphism commented Oct 30, 2012

@graydon said r+. I'm just waiting for the try build to finish and then I'll commit this. (We agreed that @nikomatsakis has a point insofar as it's important to not break syntax extensions, but also agreed to commit this now on the grounds that it fixes test cases and doesn't make things any worse. We can revisit in the future.)

Contributor

catamorphism commented Oct 30, 2012

Merged: 165ce1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment