On 6/16/2014 12:23 PM, Sylvestre Ledru wrote:
Hello,
I am working on providing weekly code coverage of Firefox code.
For now, I am able to do that for C/C++ code.
I would like to know if anyone tried to generate code coverage recently
on the Javascript code of Firefox (or Firefox OS)?
Define recently? :-)
I've done at least three different abortive attempts to do JS code
coverage. The really hard part is that Mozilla uses new (and
non-standard) syntax fairly aggressively in its code--when I first
started poking at it, the inability to process E4X was actually a hard
block for me [1]. I also tried to do some poking to figure out how to
get it working on inline scripts in our XUL or XBL code.
My first attempt was using jscoverage, which worked poorly even back in
2010 and 2011: it was based on an earlier version of SpiderMonkey's APIs
and upgrading to newer parse APIs was a pain in the butt. I tried again
at some point using the Reflect.parse APIs, but shied away from that
because I didn't have the time to maintain a functional decompiler from
the AST let alone a variant that added the instrumentation to that. When
the SpiderMonkey PC counts API was added, I actually managed to build a
working system, but then I was told that IonMonkey had broken that
functionality before I could ever get it truly ready. I tried once again
when the debugger API was added, but that again didn't work for some
reason (I've forgotten why long ago... probably something to do with
insufficiently exposing interesting globals?).
Over the years, I've come to the conclusion that inserting
instrumentation into the source code is not a viable path to achieving
JS code coverage metrics. Maintaining a functioning decompiler for the
AST that works reasonably well on several million lines of JS code, some
of which uses dialects not commonly found on the web, is a difficult
task by itself. Adding on top of that the insanity of how JS code must
be expressed (including nasty things like you can't instrument prefs.js
or the presence of inline JS) means that you have to spend more time on
maintaining an engine beyond what most others would find sufficient for
their uses. On top of that, there is the not-insignificant problem that
there's no standard way to do I/O in JS that lets you save that
information somewhere: especially daunting given the presence of XPCOM
components, chrome workers, content workers, chrome and content windows,
specifically sandboxed source files, and builtin JS code, to name the
types I'm aware of.
[1] I concern myself more with Thunderbird's code coverage than with
Firefox's, and we used E4X in one place before it was removed, and
Lightning used it in another place.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
