The patch removes no longer used XPCJSRuntime::mJSCycleCollectionContext,
nsXPConnect::mCycleCollectionContext and related code to create/destroy
contexts. As that made nsCycleCollectionJSRuntime::FinishTraverse() empty
in all cases I removed that method as well.
This will help integration with the jstests framework, which also uses
a single prefix argument to its Test command construction method.
Note that the order of js arguments is changed, from:
cmd = [js] + list(set(self.jitflags)) + shell_args + ['-e', expr]
cmd += ['-f', os.path.join(LIB_DIR, 'prolog.js'), '-f', self.path]
to:
prefix = [os.path.abspath(args[0])] + shlex.split(options.shell_args)
prefix += ['-f', os.path.join(jittests.LIB_DIR, 'prolog.js')]
cmd = prefix + list(set(self.jitflags)) + ['-e', expr, '-f', self.path]
The assumption here is that only the order of -f options matters.
These paths are a little far away from the script they're referenced in, so
it's a little fragile. However, since (a) these aren't expected to change
that often, and (b) the code should fail conspicuously if there is a change,
I don't think it's a problem.
The behavior here is a bit weird because Document is still not a
WebIDL object, so calling createNodeIterator or createTreeWalker via
an Xray will call the XPCOM versions of those methods. That means
that I can't just disable XPCOM-based wrapping for TreeWalker and
NodeIterator altogether, unfortunately, which means a web page could
try stashing a TreeWalker in something like userdata and then getting
it back and end up wrapping it as an XPCOM object the second time.
I could "fix" that by adding a wrapper cache and whatnot, I guess, if
desired... But the problem will go away once we convert Document in
any case.
This does allow people to accidentally hit the slower path through use
of non-const strings, but I think that's OK now that we're mostly
autogenerating this stuff
The behavior here is a bit weird because Document is still not a
WebIDL object, so calling createNodeIterator or createTreeWalker via
an Xray will call the XPCOM versions of those methods. That means
that I can't just disable XPCOM-based wrapping for TreeWalker and
NodeIterator altogether, unfortunately, which means a web page could
try stashing a TreeWalker in something like userdata and then getting
it back and end up wrapping it as an XPCOM object the second time.
I could "fix" that by adding a wrapper cache and whatnot, I guess, if
desired... But the problem will go away once we convert Document in
any case.
This does allow people to accidentally hit the slower path through use
of non-const strings, but I think that's OK now that we're mostly
autogenerating this stuff
There were merges in configure.in and some Makefile.in. None had any
conflicts. I spot verified the Makefile.in changes and confirmed that
the changes did not touch any DIRS* variables.
