Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] JSDT Parser
On Mon, Mar 14, 2016 at 12:00 PM, Gorkem Ercan <gorkem.ercan@xxxxxxxxx> wrote:


On 14 Mar 2016, at 11:33, Doug Schaefer wrote:

Thanks Michael. I guess I'm still confused. Max mentioned that JSDT was
using Orion, but I haven't seen much evidence of that.

 We are not using Orion, we use the same bits as Orion for instance our
new parser is esprima 2.7.2 and we are looking into using eslint and
tern.js but these are likely to happen next year.

I highly encourage
you do that (and by extension my QML work does that) to leverage as much of
the expertise on the Orion project as possible, especially as they work to
make their bits more consumable by other IDEs.

 Yes, Max mentioned that too but I am looking at the docs and I can not find
something like a _javascript_ language service, which was my expectation from
the word of mouth. I would appreciate if someone can point me in the right
direction.

It came out of a conversation I had with Steve Northover at EclipseCon. This is for Orion 12 I believe. They are building an integration that can be used with Sublime, but are doing so that any IDE could leverage. At the end of the day, Orion will be a collection of npm modules. Very interesting idea.

BTW, Sublime is Eclipse's biggest competitor in the web space from what I see. An Orion integration with Sublime raises the bar even higher.
 


[1] https://wiki.eclipse.org/Orion/Documentation/Developer_Guide



Doug.

On Mon, Mar 14, 2016 at 11:26 AM, Michael Rennie <Michael_Rennie@xxxxxxxxxx>
wrote:

In Orion, we have a modified version of Esprima (its a bit old now,
version 2.0), that has more tolerance in it than the stock Esprima does. It
might provide the level of recovery you are looking for.

Our recovery is done in a few ways:

1. we catch and record all exceptions, to make it far less 'throwy'
2. we perform node fill-ins when an exception would leave the AST is bad
state
3. in some cases we rewind and try again based on state / tokens / and
line endings

Our version can be found here:


http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client._javascript_/web/esprima/esprima.js

The tests we run on it (to give an idea of the kinds of things we can
recover from):


http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client._javascript_/web/js-tests/_javascript_/esprimaTolerantTests.js

And lastly, the bug for us to upgrade to the latest version of Esprima:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=473765

Michael Rennie



----- Original message -----
From: Eugene Melekhov <emvv@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
To: "General discussion of project-wide or architectural issues." <
wtp-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [wtp-dev] JSDT Parser
Date: Sat, Mar 12, 2016 10:31 AM

Angelo,

Yes, sure, I used that option. The problem is that esprima actually throws
a lot of syntax exceptions:

grep -c throwUnexpectedToken esprima.js
56
grep -c tolerateUnexpectedToken esprima.js
29

That means that in 2/3 error cases it throws exception and tolerate only
1/3. Shift meanwhile doesn't throws exceptions
in "Early Error" cases like this 0=0, which is tolerated by esprima. I
have a suspicion that most of esprima
"tolerated errors" are from that "Early Error" category, which means that
in fact Shift behaves like esprima :-)

I thought that it would be interesting to compare shift and esprima
behavior on large enough set of erroneous code
fragments. It might happen that they are very close actually :-)


I'm not a big expert with esprima, but do you use tolerant option like
explained at http://esprima.org/doc/ ?

2016-03-12 10:25 GMT+01:00 Eugene Melekhov <emvv@xxxxxxx>:

Angelo,

One more thing about parser tolerance. esprima for example throws an
exception parsing this "relatively simple"
declarations:

//function foo(a, b {}

//function foo(a, b, c,) {}

//function foo(a, b, {} {}


Yes sure, but it seems that Shift doesn't support tolerant parser
which is very required for a JS editor. See
https://github.com/shapesecurity/shift-java/issues/93



--
Eugene Melekhov

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev





--
Eugene Melekhov

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev



_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Back to the top