Closed Bug 243252 Opened 18 years ago Closed 3 years ago

Add JS syntax checking to tinderbox

Categories

(Testing :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bzbarsky, Assigned: gbrown)

References

()

Details

Brendan just added a compileFile function to xpcshell:

   "if the compileFile function succeeds, it returns the Script object it
    compiled, so you could call it (execute it), or disassemble it, etc."

The function throws on compile errors.  We can use this to do JS validity (at
least as far as compiling goes) tests on tinderbox (and have it go red on
invalid JS).

If someone can give me an idea for where to look for info on getting this hooked
up to tinderbox, that would be much appreciated....
I suppose you could probably use xpcshell to drive this.
My novice advice for hooking it up is to duplicate a working test in
build-seamonkey-utils.pl, and hack on that.  I'm not sure how you'd generate the
list of JS files to inspect since many of them will be inside JAR files.
Can I assume tinderbox has a functioning "unzip"?  ;)
unzip is pretty common, if it's not there we can put it there.
Then one can just unzip the jars and search for js files.... (harder on the
non-unix boxes, I guess....)
cygwin has unzip, so no problem on windows.
of course, if you use xpcshell, then you could also use libjar! ;-)
maybe it would be better to integrate this with the build system, which can run
xpcshell on the .js files before they are jarred up, but after they are
preprocessed?
i'm playing with this on boffo using a rather simple script (which will appear
in the build log
<http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1084281000.1925.gz>).
note that there's already a list of all the js files in jars, and because we
have a source tree handy, we don't need to go hunting for things. 

well, that works until someone preprocesses js files.

darin's right, it'd probably be better to use jar urls in xpcshell and have it
just compile streams. I don't see the point of a compileFile, the only thing it
did was cause conflicts for me :).

Note that in order to make this stuff really work you need to provide a dom
environment. I'll probably play w/ that at some time in the future as I have
other interests which benefit from it.

my first estimate at a dom world:
javascript:(function(){var a=[]; for (b in window) if (typeof
window[b]=='function') a.push(b+'=function
'+b+'(){checkArity(arguments.length,'+window[b].arity+')}'); else
a.push(b+'=null'); a.push('checkArity=function checkArity(actual, expected) {if
(actual<expected) throw "actual["+actual+"]<expected["+expected+"]"}');
a.push('window=this'); a.push(''); prompt('',a.join(';'));})()

checkArity is of course not really legal, and you have to do a lot more to get a
usable dom world.
> well, that works until someone preprocesses js files.

We absolutely have to be doing this post-preprocessing...
timeless: there is no requirement for a DOM environment to do JS syntax
checking.  There is absolutely a requirement to work with post-processed files.

/be
brendan, well... if that's all you want then see
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1084285560.2619.gz

but note that most files have reference errors about window.

I could teach boffo about preprocessing, but not right now.
timeless: no, I do not want any of these scripts executed.  Just compiled, which
is why I added compileFile to xpcshell.  There's no way to compile but not
execute currently, in the apps or shells.

/be
brendan: well, how about adding a compileString function? in all likelyhood
we're going to be pulling the data from the jar file and don't want to dump them
to disk.

as to your claim about no way to do this from a shell. you're mistaken.
in a mozilla/xpcshell built w/
ac_add_options --enable-xpctools

you can do:
js>
xpcc=Components.classes["xpctools.compiler.1"].createInstance(Components.interfaces.nsIXPCToolsCompiler)
[xpconnect wrapped nsIXPCToolsCompiler @ 0xf85ac8]
js>
file=Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile)
[xpconnect wrapped nsILocalFile @ 0xf8c998]
js> file.initWithPath("c:\\nsError.js")
js> xpcc.CompileFile(file, true)
js> file.initWithPath("c:\\test.js")
js> xpcc.CompileFile(file, true)
SyntaxError: missing ( before formal parameters [c:\test.js,1]

js> quit()
R:\mozilla\all-i586-pc-msvc\dist\bin>type c:\test.js
function ){}

R:\mozilla\all-i586-pc-msvc\dist\bin>
timeless: thanks, I had forgotten about that beast, entirely.

Now that you mention it, there's no need for any compileFile extension.  The
Script object provides all the compiling power we need, without executing.  If
you get a string from a jar file containing a .js file's source, call it s, then:

  try { Script(s); } catch (e) { report the SyntaxError in s here; }

should suffice.  Let me know and I'll undo my xpcshell.cpp change.

/be
please do so, although if possible, do it when i'm around so that i can clean up
after the merge conflicts that are on boffo.
Dawn's not around, AFAICT.  Who will take this bug?  Bryner?

/be
Depends on: 246286
Dawn's not around anymore, reassigning to default...
Assignee: endico → dbaron
Assignee: dbaron → mcafee
Component: Tinderbox Configuration → Tinderbox
Product: mozilla.org → Webtools
QA Contact: mcafee → timeless
Version: other → Trunk
we now have "make check" (though not yet integrated into tbox), and we have a
syntax check option for xpcshell (bug 306740) -- should "make check" run that
syntax check on each .js file it either puts into a jar or installs as a component?

or, should the libs:: target do this even?
QA Contact: timeless → tinderbox
Severity: normal → enhancement
Assignee: mcafee → nobody
Component: Tinderbox → General
OS: Linux → All
Product: Webtools → Testing
QA Contact: tinderbox → general
Hardware: PC → All
Version: Trunk → unspecified
Assignee: nobody → gbrown
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.