The problem with having two regexp implementations, one of which compiles a subset of the other, is that the overlap may not yield consistent results. For tests like those in bug 576828 we really want to be able to run the comparison twice if there is a disable-the-JIT capability available to the shell, once with the JIT enabled and once with the JIT disabled. This bug should also make a little effort to convert some of the existing tests over to a harness that could compare regexp results with the JIT both on and off, but I really would like to have it for tests going forward.
(In reply to comment #1) Oh yeah, and the reason I don't want to rip out options (and instead have added a new interface, optionsNG) is because the test infrastructure is intertwingled with the way that the options() functionality currently works, which is a bit of an overhaul. Now that I think about it, I probably need to make an optionsNG() interface like the current one in js/tests/browser.js for compatibility with browser reftests.
Right now in the code base: You enable YARR (instead of PCRE) by turning on |ENABLE_YARR_JIT| You turn on the YARR JIT by having |ENABLE_YARR_JIT && defined(METHODJIT)| This is clearly broken and should only require some quick lovin' to fix. Luckily, that's the kind of lovin' I'm good at.
For bug 691898 we'll want a preprocessor seam, as well as the runtime option we want for fuzz testing.
Mass-reassigning cdleary's bugs to default. He won't work on any of them, anymore. I guess, at least. @cdleary: shout if you take issue with this.
bhackett: is this "disable regexp JIT" option still relevant now that YARR has been with irregexp?
No, this bug is just about yarr, which has been removed entirely. Irregexp has both an interpreter and a JIT and there is an option for using the former instead of the latter (--no-native-regexp in the shell).