* SUMMARY Improve ScriptSyntaxTree a bit. - Share and fix ClassDeclaration and ClassExpression recursion to visit the identifier (node.id) - Include the kind with a VariableDeclaration ("var", "let", "const")
<rdar://problem/22470522>
Created attachment 260126 [details] [PATCH] Proposed Fix
=
Comment on attachment 260126 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=260126&action=review > Source/WebInspectorUI/UserInterface/Models/ScriptSyntaxTree.js:881 > + kind: node.kind Shoulder map this to an enum?
Comment on attachment 260126 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=260126&action=review >> Source/WebInspectorUI/UserInterface/Models/ScriptSyntaxTree.js:881 >> + kind: node.kind > > Shoulder map this to an enum? Should we*
(In reply to comment #5) > Comment on attachment 260126 [details] > [PATCH] Proposed Fix > > View in context: > https://bugs.webkit.org/attachment.cgi?id=260126&action=review > > >> Source/WebInspectorUI/UserInterface/Models/ScriptSyntaxTree.js:881 > >> + kind: node.kind > > > > Shoulder map this to an enum? > > Should we* Currently we just carry over all the other basic properties from esprima right now. Ultimately we would want our own enum types here (and in all other nodes) if we really want ScriptSyntaxTree to abstract any parser. FWIW, there has been discussion of standardizing JS ASTs and their types in ESTree: https://github.com/estree/estree https://github.com/estree/estree/blob/master/es6.md Esprima _very_ closely matches that. I did notice a few minor differences that can be sorted out later (what is a MetaProperty?). But ultimately if JS AST generators produce ESTree ASTs swapping out any parser would be trivial.
Also interesting JavaScript "CSTs": https://github.com/mdevils/cst > CST means Concrete Syntax Tree. Unlike an AST (Abstract Syntax Tree), > a CST contains all the information from the JavaScript source file: > whitespace, punctuators, comments. This information is extremely > useful for code style checkers and other code linters. CST is also > useful for cases when you need to apply modifications to existing > JavaScript files while preserving the initial file formatting. > > This CST implementation is designed to be 100% compatible with JS AST > (https://github.com/estree/estree). I think an issue I ran into just yesterday could have benefitted from original source information instead of just token information. Likewise, our PrettyPrinter could be written to use this. Using ASTs we lacked whitespace information that was useful to keep "as authored".
(In reply to comment #5) > Comment on attachment 260126 [details] > [PATCH] Proposed Fix > > View in context: > https://bugs.webkit.org/attachment.cgi?id=260126&action=review > > >> Source/WebInspectorUI/UserInterface/Models/ScriptSyntaxTree.js:881 > >> + kind: node.kind > > > > Shoulder map this to an enum? > > Should we* I think we should. We could follow what we do for node types here and just make everything a Symbol.
Comment on attachment 260126 [details] [PATCH] Proposed Fix Clearing flags on attachment: 260126 Committed r189118: <http://trac.webkit.org/changeset/189118>
All reviewed patches have been landed. Closing bug.