Bugzilla – Full Text Bug Listing
| Summary: | Update to Esprima 1.1.0-dev | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Michael Rennie <Michael_Rennie> | ||||
| Component: | JS Tools | Assignee: | Michael Rennie <Michael_Rennie> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, mamacdon | ||||
| Version: | 5.0 | ||||||
| Target Milestone: | 6.0 M2 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 432956 | ||||||
| Attachments: |
|
||||||
|
Description
Michael Rennie
Our content assist story relies on the parser being tolerant, and we even had our own code to make it so, but that support will be hard to merge in 1.1.0 due to: https://code.google.com/p/esprima/issues/detail?id=398 - the patch() / unpatch() pair have been removed in favour of using tokenize(source, options) rather than visiting an AST. I'll have to investigate if we can make use of this new support. I think though that we will still want the parsing to be tolerant so the rest of the tooling works for incomplete-edited source. We decided to defer this one for now, there is nothing in 1.1.0 that is blocking us so we will see if Esprima has any interest in providing the tolerant support we require for Orion. See the Esrpima bugs: https://code.google.com/p/esprima/issues/detail?id=398 https://code.google.com/p/esprima/issues/detail?id=130 Created attachment 241229 [details]
towards tolerant Esprima
This is a work in progress for merging the recovery from our custom Esprima into the master branch (back in January)
(In reply to Michael Rennie from comment #3) > Created attachment 241229 [details] > towards tolerant Esprima > > This is a work in progress for merging the recovery from our custom Esprima > into the master branch (back in January) Aria commented that we should check out: http://espadrine.github.io/aulx/ which looks like it does content assist using the token stream from Esprima. (In reply to Michael Rennie from comment #4) > Aria commented that we should check out: http://espadrine.github.io/aulx/ > which looks like it does content assist using the token stream from Esprima. From a quick scan, it seems that Aulx does use the tokens somehow, but it relies on a static analysis of the AST to compute type information. The type info gets cached, and used thereafter to provide suggestions as you write code. This is a neat idea for content assist. (Type info typically doesn't change on every keystroke, so using a cache might be OK, and performs better than parsing the AST on every invocation.) But it still relies on getting a clean parse at some point, which means it doesn't solve our problem. I'll try taking a closer look. Perhaps I missed something. Mark finished the merging, wrote some tests and merged the new version of Esprima with master (yay): http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=9ed857985d8faf88fbd1d934ac88d50d19cbdb07 The new version is not running as the default yet as we are still testing it. The Esprima was made the default as part of the commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=0abe51a10fe70ef9c82327ac6644f86f15a62e28 We can open any issues we (hopefully don't) find in separate bugs. |