Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "JSDT/JSDT Code Analytics"
| Line 21: | Line 21: | ||
We're using Closure Compiler because of its good performances and architecture ([http://eclipse.1072660.n5.nabble.com/About-parsing-and-conversion-times-td181113.html See discussion] [https://dev.eclipse.org/mhonarc/lists/wtp-dev/msg09853.html #]). | We're using Closure Compiler because of its good performances and architecture ([http://eclipse.1072660.n5.nabble.com/About-parsing-and-conversion-times-td181113.html See discussion] [https://dev.eclipse.org/mhonarc/lists/wtp-dev/msg09853.html #]). | ||
| + | There are a lot of resources about CC: [https://github.com/google/closure-compiler/wiki/Tutorials tutorials], | ||
| + | [https://github.com/google/closure-compiler/wiki/FAQ FAQs], | ||
| + | [https://github.com/google/closure-compiler/wiki/Design-Documents design documents] | ||
| − | + | Closure Compiler provides | |
| − | + | We could extend Closure Compiler | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Ideas: | Ideas: | ||
Revision as of 05:58, 19 April 2017
Contents
JSDT Code Analytics
JSDT 2.0 is missing the content outline and content proposal functionality.
- In JSDT 1.0 we used to parse all the .js files with Rhino and to store the AST in memory. With the full AST in memory, it was easy to generate a content outline tree and then to use an inference engine to provide the content assist.
- In JSDT 2.0 we introduced tolerant parsing, but we parse only the .js files which are open in the editor. Also, we do not load the full AST in memory, and we do not generate a full content outline tree and the content assist is not good enough.
Despite JSDT 2.0 is modern and fast, we should fix content outline and content assist for making users happy, (ie Bug 510677#c3).
Improve JSDT 2.0
How can we improve JSDT by restoring the content outline and the content proposal?
- We need to parse all the .js sources with a fast parser and produce an output tree.
- with the output tree, we should build the content outline: the JavaScript object hierarchy
- with the output tree, and the current position in code, we should feed an inference engine, to give content assist proposals.
Current Status
We're using Closure Compiler because of its good performances and architecture (See discussion #).
There are a lot of resources about CC: tutorials, FAQs, design documents
Closure Compiler provides We could extend Closure Compiler
Ideas:
- we could use a tolerant parser, who can produce a partial tree when the source has errors, like Tern/Acorn
- we could generate a content tree
Parsers
= Closure Compiler
We currently use Closure Compiler in JSDT.
Tern
Tern.js is a code-analysis engine for JavaScript written in javascript. It is a good model for the functionalities we want to improve. As a downside, it requires loading all the source files, which should be sent POST to an http server.
Js Program
We could write a .js program which loads all the available source files, and then outputs a json file with all the information needed to build a content tree and store it on disk. Then, we could use the .json file on disk to infer the suggestions.