You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AST nodes with parenthesized type child nodes include child's parens in source location
Summary:
The Hermes parser is fixing its handling of source locations around parenthesized types and expressions (choosing to follow the same rules as Flow and Babel). When an expression or type node is parenthesized, the source location of the node correctly does not contain the parentheses. However currently when a parent node has a parenthesized expression or type child node, Hermes is inconsistently including the child's parens in the parent's source location. Hermes should instead always include the child's parentheses in the parent node's source location. For example:
```
(1 + 2) * (3 + 4)
^^^^^ ^^^^^ // Left and right inner expr locs do not contain parens
^^^^^^^^^^^^^^^^^ // Parent binary expression node does contain parens of children
```
We also can now check the end location of the previous token using `getPrevTokenEndLoc`, which will be used to calculate source locations in this scheme instead of building up source locations from child nodes (as child nodes will not contain their own parentheses in their source locations).
This diff fixes parenthesized source locations for all Flow type nodes in `JSParserImpl-flow.cpp`. The rules for are as follows:
1. If a node can begin with a type or expression node in the source text, then we must save the start source location before parsing that initial type or expression. This will be the start location of the first paren that wraps that type/expression node, if any exist.
2. If a node can end with a type or expression node in the source text, then we must call `getPrevTokenEndLoc` after the last type/expression node has been parsed. This will be the end location of the first paren that wraps that type/expression node, if any exist.
This diff then goes through and implements these rules for every Flow node that can begin or end with a type or expression node.
In addition, this diff replaces cases where the end location is explicitly calculated from multiple potential end nodes with a single call to `getPrevTokenEndLocation` at the end of the node. This was done for `GenericTypeAnnotation` nodes and `ClassImplements` nodes.
Reviewed By: avp
Differential Revision: D25291377
fbshipit-source-id: 35fda8f4e8e92e1197a5e67600bce8ed91e88269
0 commit comments