243252 - Add JS syntax checking to tinderbox

Status: RESOLVED WONTFIX

(Testing :: General, enhancement)

Description

[Boris Zbarsky [:bzbarsky]]

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....

Comment 1

[Darin Fisher]

I suppose you could probably use xpcshell to drive this.

Comment 2

[Darin Fisher]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Can I assume tinderbox has a functioning "unzip"?  ;)

Comment 4

[Chris McAfee]

unzip is pretty common, if it's not there we can put it there.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Then one can just unzip the jars and search for js files.... (harder on the
non-unix boxes, I guess....)

Comment 6

[Chris McAfee]

cygwin has unzip, so no problem on windows.

Comment 7

[Darin Fisher]

of course, if you use xpcshell, then you could also use libjar! ;-)

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

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?

Comment 9

[timeless]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> well, that works until someone preprocesses js files.

We absolutely have to be doing this post-preprocessing...

Comment 11

[Brendan Eich [:brendan]]

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

Comment 12

[timeless]

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.

Comment 13

[Brendan Eich [:brendan]]

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

Comment 14

[timeless]

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>

Comment 15

[Brendan Eich [:brendan]]

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

Comment 16

[timeless]

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.

Comment 17

[Brendan Eich [:brendan]]

Dawn's not around, AFAICT.  Who will take this bug?  Bryner?

/be

Comment 18

[Dave Miller [:justdave]]

Dawn's not around anymore, reassigning to default...

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

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?