Add a dummy change to old-configure.in so that old-configure is
force-refreshed.
Differential Revision: https://phabricator.services.mozilla.com/D16797
--HG--
extra : moz-landing-system : lando
InterpreterFrameInfo is just a very simple interface on top of masm.
CompilerFrameInfo maintains the virtual stack based on the script it's
compiling.
Differential Revision: https://phabricator.services.mozilla.com/D16480
--HG--
extra : moz-landing-system : lando
The interpreter won't use the virtual stack and StackValue, so we need to
refactor things a bit so we don't call frame.peek(x) outside the FrameInfo class.
StackValue will be just an implementation detail of CompilerFrameInfo in the
next patch.
Differential Revision: https://phabricator.services.mozilla.com/D16479
--HG--
extra : moz-landing-system : lando
We're not handling lexical variable in BinAST parser for now, and
it results in unhelpful error at the first reference.
Detecting the lexical variable at declaration and throw more helpful error.
Differential Revision: https://phabricator.services.mozilla.com/D16807
--HG--
extra : moz-landing-system : lando
JSOPs like JSOP_INT8 that depend on the pc need to be specialized now for the
interpreter. I added MOZ_CRASH versions of these that we can implement later.
This split is a bit pessimistic: we should actually (partially) share codegen
for some of these ops like JSOP_RESUME. However it's easier to revisit this
later when we need to implement these ops for the interpreter.
Differential Revision: https://phabricator.services.mozilla.com/D16442
--HG--
extra : moz-landing-system : lando
The next patch will template-specialize some of the emit_JSOP_FOO methods, but
the C++ compiler wants that to happen before we call these methods in emitBody.
Differential Revision: https://phabricator.services.mozilla.com/D16441
--HG--
extra : moz-landing-system : lando
Interpreter and compiler will implement these differently, but this allows
sharing codegen for a large number of JSOps.
Differential Revision: https://phabricator.services.mozilla.com/D16438
--HG--
extra : moz-landing-system : lando
Since js configure is also python configure, we can actually create
a ConfigureSandbox directly, with the right environment and arguments.
Depends on D16668
Differential Revision: https://phabricator.services.mozilla.com/D16669
--HG--
extra : moz-landing-system : lando
Use an I/O wrapper on the configure output handler to add the "js/src>"
prefix.
Depends on D16643
Differential Revision: https://phabricator.services.mozilla.com/D16644
--HG--
extra : moz-landing-system : lando
Instead, include the module and inline its main function.
Depends on D16622
Differential Revision: https://phabricator.services.mozilla.com/D16623
--HG--
extra : moz-landing-system : lando
This happens to remove the last use of perl from configure.
Depends on D16621
Differential Revision: https://phabricator.services.mozilla.com/D16622
--HG--
extra : moz-landing-system : lando
This simplifies LexicalEnvironmentObject::thisValue so it's easier to inline in JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D16586
--HG--
extra : moz-landing-system : lando
I think it's a little bizarre for this to be part of the standard, but if it
weren't there, I wouldn't know it was safe to do this.
Differential Revision: https://phabricator.services.mozilla.com/D14511
--HG--
extra : moz-landing-system : lando
ExecutableAllocator.py's PoolIterator is a Python 3 iterator in that
it defines the __next__ method. Defining |next| as well lets this
code work in Python 2.
MozReview-Commit-ID: JlkSsZHZkpw
Differential Revision: https://phabricator.services.mozilla.com/D16500
--HG--
extra : moz-landing-system : lando
