@@ -63,15 +63,15 @@ Some details of the philosophy behind the implementation.
63
63
### Operate on the AST
64
64
65
65
A reformatting tool can be based on either the AST or a token stream (in Rust
66
- this is actually a stream of token trees, but its not a fundamental difference).
66
+ this is actually a stream of token trees, but it's not a fundamental difference).
67
67
There are pros and cons to the two approaches. I have chosen to use the AST
68
68
approach. The primary reasons are that it allows us to do more sophisticated
69
69
manipulations, rather than just change whitespace, and it gives us more context
70
70
when making those changes.
71
71
72
- The advantage of the tokens approach are that you can operate on non-parsable
72
+ The advantage of the tokens approach is that you can operate on non-parsable
73
73
code. I don't care too much about that, it would be nice, but I think being able
74
- to perform sophisticated transformations is more important. In the future I hope to
74
+ to perform sophisticated transformations is more important. In the future, I hope to
75
75
(optionally) be able to use type information for informing reformatting too. One
76
76
specific case of unparsable code is macros. Using tokens is certainly easier
77
77
here, but I believe it is perfectly solvable with the AST approach. At the limit,
@@ -80,7 +80,7 @@ we can operate on just tokens in the macro case.
80
80
I believe that there is not in fact that much difference between the two
81
81
approaches. Due to imperfect span information, under the AST approach, we
82
82
sometimes are reduced to examining tokens or do some re-lexing of our own. Under
83
- the tokens approach you need to implement your own (much simpler) parser. I
83
+ the tokens approach, you need to implement your own (much simpler) parser. I
84
84
believe that as the tool gets more sophisticated, you end up doing more at the
85
85
token-level, or having an increasingly sophisticated parser, until at the limit
86
86
you have the same tool.
@@ -99,7 +99,7 @@ to good old fashioned abstraction and code sharing. This will give a bigger code
99
99
base, but hopefully a better result.
100
100
101
101
It also means that there will be some cases we can't format and we have to give
102
- up. I think that is OK. Hopefully they are rare enough that manually fixing them
102
+ up. I think that is OK. Hopefully, they are rare enough that manually fixing them
103
103
is not painful. Better to have a tool that gives great code in 99% of cases and
104
104
fails in 1% than a tool which gives 50% great code and 50% ugly code, but never
105
105
fails.
@@ -150,9 +150,9 @@ for its configuration.
150
150
151
151
Our visitor keeps track of the desired current indent due to blocks (
152
152
` block_indent ` ). Each ` visit_* ` method reformats code according to this indent,
153
- ` config.comment_width() ` and ` config.max_width() ` . Most reformatting done in the
154
- ` visit_* ` methods is a bit hacky and is meant to be temporary until it can be
155
- done properly.
153
+ ` config.comment_width() ` and ` config.max_width() ` . Most reformatting that is done
154
+ in the ` visit_* ` methods is a bit hacky and is meant to be temporary until it can
155
+ be done properly.
156
156
157
157
There are a bunch of methods called ` rewrite_* ` . They do the bulk of the
158
158
reformatting. These take the AST node to be reformatted (this may not literally
@@ -163,7 +163,7 @@ code in the box given by the indent and width budget. If the method fails, it
163
163
returns ` None ` and the calling method then has to fallback in some way to give
164
164
the callee more space.
165
165
166
- So, in summary to format a node, we calculate the width budget and then walk down
166
+ So, in summary, to format a node, we calculate the width budget and then walk down
167
167
the tree from the node. At a leaf, we generate an actual string and then unwind,
168
168
combining these strings as we go back up the tree.
169
169
0 commit comments