Community
Participate
Working Groups
We should investigate the viability of providing a Rhino builder for JavaScript - something like what the JSDT validator does, except powered by Rhino.
Created attachment 183230 [details] fix The patch provides a Rhino incremental builder, that creates Rhino JavaScript Problems for any errors it finds. The build can be set up on any kind of project using the standard Configure > popup menu and selecting Enable Rhino Builder (or Disable Rhino Builder if you want to remove it). The placement of error markers is a bit off sometimes due to the reported problem offsets from the Rhino parser. I opened https://bugzilla.mozilla.org/show_bug.cgi?id=612346 to track the issue.
After using this for a day or so installed in my host, I find it useful that I get incremental errors if I forget a semi-colon or this like, but far more annoying because the errors reported from Rhino are often cryptic (and reported in the wrong spot). Take for example this error: Description Resource Path Location Type missing name after . operator activation.js /firebug1.7/content/firebug line 63 Rhino JavaScript Problem on the snippet: // Import annotation service. Components.utils.import(<error marker here>"resource://firebug/firebug-annotations.js"); or this one: Description Resource Path Location Type missing ) after argument list debugger.js /firebug1.7/content/firebug line 2507 Rhino JavaScript Problem on the snippet: filterMenuUpdate: <error marker here>function() { I think to make this truly useful we would have to beef up the messages that are reported to give more information about what is being reported and why.
Created attachment 183474 [details] updated builder Updated builder with progress + better performance, still does not handle the cryptic messages though
So the output from Rhino completely uncontrollable?
(In reply to comment #4) > So the output from Rhino completely uncontrollable? It depends what you mean by controllable. If you mean can I interrupt the parser in some way at any given point, than yes it seems to be uncontrollable. Otherwise you do get a fair amount of information during the parse like: 1. the kind of problem (error / warning) 2. the string line of source the problem occurs on, 3. the offset into that line that the problem is reported against 4. the human readable error message for the problem There could be more, and there could also be additional ways to hook the parser, this builder was a quick experiment to see if it could be done (not necessarily the best way to do it).
