Re: [wtp-dev] JSDT Parser

Mon, 14 Mar 2016 10:31:26 -0700 


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


On Mon, Mar 14, 2016 at 12:00 PM, Gorkem Ercan 
<gorkem.er...@gmail.com>

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.


Correct, but won’t fly if Orion continues to use forked 3rd party 
libraries.



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_ren...@ca.ibm.com>
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 <e...@mail.ru>
Sent by: wtp-dev-boun...@eclipse.org
To: "General discussion of project-wide or architectural issues." <
wtp-dev@eclipse.org>
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 <e...@mail.ru>:




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@eclipse.org

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@eclipse.org

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@eclipse.org

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@eclipse.org

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@eclipse.org

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@eclipse.org

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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev
























					Reply via email to