Closed
Bug 243252
Opened 20 years ago
Closed 6 years ago
Add JS syntax checking to tinderbox
Categories
(Testing :: General, enhancement)
Testing
General
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....
Comment 1•20 years ago
|
||
I suppose you could probably use xpcshell to drive this.
Comment 2•20 years ago
|
||
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.
Reporter | ||
Comment 3•20 years ago
|
||
Can I assume tinderbox has a functioning "unzip"? ;)
Comment 4•20 years ago
|
||
unzip is pretty common, if it's not there we can put it there.
Reporter | ||
Comment 5•20 years ago
|
||
Then one can just unzip the jars and search for js files.... (harder on the non-unix boxes, I guess....)
Comment 6•20 years ago
|
||
cygwin has unzip, so no problem on windows.
Comment 7•20 years ago
|
||
of course, if you use xpcshell, then you could also use libjar! ;-)
Comment 8•20 years ago
|
||
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.
Reporter | ||
Comment 10•20 years ago
|
||
> well, that works until someone preprocesses js files.
We absolutely have to be doing this post-preprocessing...
Comment 11•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
Dawn's not around, AFAICT. Who will take this bug? Bryner? /be
Depends on: 246286
Comment 18•19 years ago
|
||
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
Comment 19•19 years ago
|
||
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?
Updated•18 years ago
|
QA Contact: timeless → tinderbox
Updated•16 years ago
|
Assignee: mcafee → nobody
Component: Tinderbox → General
OS: Linux → All
Product: Webtools → Testing
QA Contact: tinderbox → general
Hardware: PC → All
Version: Trunk → unspecified
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → gbrown
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•