The topobjdir-finding logic in mozbuild relies on MOZ_CURRENT_PROJECT
being set, and it's currently only set when going through client.mk.

On automation, during universal builds, make check is invoked directly
in one of the objdirs, so MOZ_CURRENT_PROJECT is not set. We've had
other similar problems in the past. Ensuring MOZ_CURRENT_PROJECT is set
in the objdir itself should reduce the risk of other such issues in the
future.

Historically, a mozinfo for js standalone build has not been necessary,
but with the move towards a) having things work with mach and b)
buildconfig using the MozbuildObject.from_environment in next patch,
mozinfo becomes necessary (it's required for
MozbuildObject.from_environment to find the directory is an objdir).

Interestingly, hazard builds do both a js standalone build and a desktop
Firefox build at the same time, both of which are done with MOZCONFIG
set in the environment... with the Firefox mozconfig. The result of now
writing a mozinfo for js standalone builds is that in that case, they
end up with a reference to the mozconfig, which the build system then
reads, and finds a MOZ_OBJDIR, which then doesn't match the js
standalone build objdir. So for those builds, reset MOZCONFIG.

MozReview-Commit-ID: F1vNDqMvKVK

--HG--
extra : rebase_source : 5ae2d3c85ebff734d090bf61a757ef6e1cfd4708

Bug 918733 - have overrideMimeType throw INVALID_STATE_ERR if the XHR is in the DONE or LOADING states. r=sicking

DONTBUILD (NPOTB)

Without this, we attempt to execute "hg" as a native Win32 program
and get the dreaded "%1 is not a valid Win32 application" error because
"hg" has a shebang and only executes inside a UNIX-like shell.

MozReview-Commit-ID: 5sUrxh1IxFC

--HG--
extra : rebase_source : b01d9b2f8ffc60da320f51a1b7e8a398781c373a

--HG--
extra : rebase_source : 333768aab2f99c2a56a3717a09947e1e6b0e234d

--HG--
extra : rebase_source : ef6dd065ff8c1dd3eb1a88da8267a4d08ad92bbc

--HG--
extra : rebase_source : 0e07e6c6ce691e88e031db6b09d8aab50dce3930

Backed out changeset a3f3f077a1ec (bug 1264948) for 'warning treated as error' build failure in JitAllocPolicy.h at least on Windows XP. r=backout on a CLOSED TREE

MozReview-Commit-ID: 9XETnSBXxEW

MozReview-Commit-ID: K5r9LBQ1FO0

--HG--
extra : rebase_source : 974c969fb580b41396aa25e78f379efac96487d8

Bug 1264948 - IonBuilder::addOsrValueTypeBarrier, check for OOMs when unboxing OSR values. r=h4writer

Bug 1264948 - IonBuilder::inlineArray, check for OOMs when creating array elements without resume points. r=h4writer

Bug 1278303 part 2 - Add MInstruction::New(TempAllocator::Fallible, ...) overload to all trivial MIR Instructions. r=jandem

Bug 1264948 part 1 - Register if the LifoAlloc is supposed to be infallible or not. r=jonco,h4writer

This patch adds a new flag to the LifoAlloc structure, which would be used to
assert when we attempt to allocate a new chunk for the LifoAlloc.  This ensure
that we assert (in debug builds) if we attempt to allocate beyong the reserved
space of the ballast.

--HG--
extra : rebase_source : df9a20cc3ca80df5bf630a4ccb3a16adc4511ac5

Bug 1272239 - P2. Testcase, only tables with provider could register gethash url in listmanager. r=francois

--HG--
extra : rebase_source : 9bb3c392f9443412ad60a01467ab9c77645f81ef

--HG--
extra : rebase_source : 7f1b786db70e2de24d1d561bb329bad0d853e020

The idl-test-harness can't detect the multiple types in webidl [1], so it doesn't know about the type like "double or AutoKeyword".
The same problem also happen in VTTCue's line property, and we have already expected its fail.
Therefore, we should expect this fail before we fix the problem of idl-test-harness.

[1] http://searchfox.org/mozilla-central/source/dom/imptests/idlharness.js#375
MozReview-Commit-ID: 5XvOwdmqKDP

--HG--
extra : rebase_source : fd72ef43d1f24792a1b3e228da7a7dca9483b1da

MozReview-Commit-ID: HpSbiNFtVR0

--HG--
extra : rebase_source : 04be33322b4847c21703b284075d91d4b236b9ed

MozReview-Commit-ID: L7NF8Wu7dSF

--HG--
extra : rebase_source : 49f996ec3158ecb051f87c9a5829cfc2f807ec29