LTO changes in GCC5 make it break the assumptions made in the test-ctors
source. The simplest and more correct thing to do is to just force the
test files never to be built with LTO. They are meant to have a particular
layout that LTO might break at any time anyways.
We need to use _impl variants within mozalloc.h when they are defined because
of how mozglue.dll is linked on Windows, where using malloc/free would use
the symbols from the MSVCRT instead of ours.
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
We're using as many defaults from the configure step as we can. We're also opinionated upon the defaults, but obviously allow most compare-locales options to be specified.
There are two exceptions:
Reference language is specified to be en-US, without optional argument. This is our in-tree command, and the reference language is known.
We always clobber the merge dir, and don't give an option not to. We default to a merge dir in the objdir, so we don't need to be that paranoid as in the standalone version.
Also, compare-locales clobbers merge-dir/browser etc, so you're not going to get / removed.
--HG--
extra : rebase_source : c0f63e566779e83201708d05966f3583ae82e4ee
JS_STANDALONE builds don't need everything in mozglue; have mozglue omit the
unneeded code for such builds.
Since the SpiderMonkey binaries are now more like the other Gecko binaries, we
can remove some special cases for JS_STANDALONE in GeckoSharedLibrary,
GeckoProgram, etc. All Gecko binaries now use mozglue, which contains mfbt, so
we no longer need mention mfbt explicitly.
Add a property to the getBuildConfiguration testing function's result that
indicates whether we're using jemalloc or not.
Include the newly necessary source directories in the SpiderMonkey source
package.
I tested locally that both checks give the expected error if I
temporarily change the != to an =.
--HG--
extra : transplant_source : %01N%B9%8B%BC%1E%07%D6%AE%BA2%7B%87%FB%25Y%19%B6%A9%D3
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
--HG--
extra : transplant_source : D%D3%FE%169%05%D0X%F3KK%17%9EW%88%BCs%9B%86%5D
Sphinx has been complaining about a number of reStructuredText warnings
for a while. Fix all the ones in .rst files.
Not asking for review because this is docs only and changing .rst files
can't break anything important.
DONTBUILD (NPOTB)
This patch defines bug components for code that I have historically
touched.
--HG--
extra : rebase_source : 738916cf41ac11c094f5c15667925a7221e6446e
extra : histedit_source : 0f7d5cd869a7b239def58877a8858159219cdf59
The Files sub-context allows us to attach metadata to files based on
pattern matching rules.
Patterns are matched against files in a last-write-wins fashion.
The sub-context defines the BUG_COMPONENT variable, which is a 2-tuple
(actually a named tuple) defining the Bugzilla product and component for
files. There are no consumers yet. But an eventual use case will be to
suggest a bug component for a patch/commit. Another will be to
automatically suggest a bug component for a failing test.
--HG--
extra : rebase_source : 0f4004d364f6c2fe2b7f306823cb94313f4ebfe5
extra : histedit_source : 2beea807a122e08ba152a37beec2fcbe80981b64
We want the ability to read data from any moz.build file without needing
a full build configuration (running configure). This will enable tools
to consume metadata by merely having a copy of the source code and
nothing more.
This commit creates the EmptyConfig object. It is a config object that -
as its name implies - is empty. It will be used for reading moz.build
files in "no config" mode.
Many moz.build files make assumptions that variables in CONFIG are
defined and that they are strings. We create the EmptyValue type that
behaves like an empty unicode string. Since moz.build files also do some
type checking, we carve an exemption for EmptyValue, just like we do for
None.
We add a test to verify that reading moz.build files in "no config" mode
works. This required some minor changes to existing moz.build files to
make them work in the new execution mode.
--HG--
extra : rebase_source : 2f39e19c2eb11f937da85d41b9a514ca810d6be0
extra : source : af07351bf2d6e85293ae3edf0fe4ae6cbc0ce246
The Files sub-context allows us to attach metadata to files based on
pattern matching rules.
Patterns are matched against files in a last-write-wins fashion.
The sub-context defines the BUG_COMPONENT variable, which is a 2-tuple
(actually a named tuple) defining the Bugzilla product and component for
files. There are no consumers yet. But an eventual use case will be to
suggest a bug component for a patch/commit. Another will be to
automatically suggest a bug component for a failing test.
--HG--
extra : rebase_source : 9489738136d929a53db7f54bbe6acf3186e0a47c
We want the ability to read data from any moz.build file without needing
a full build configuration (running configure). This will enable tools
to consume metadata by merely having a copy of the source code and
nothing more.
This commit creates the EmptyConfig object. It is a config object that -
as its name implies - is empty. It will be used for reading moz.build
files in "no config" mode.
Many moz.build files make assumptions that variables in CONFIG are
defined and that they are strings. We create the EmptyValue type that
behaves like an empty unicode string. Since moz.build files also do some
type checking, we carve an exemption for EmptyValue, just like we do for
None.
We add a test to verify that reading moz.build files in "no config" mode
works. This required some minor changes to existing moz.build files to
make them work in the new execution mode.
--HG--
extra : rebase_source : f701417f83dfa4e196e39182f8d0a6fea46c6fbb
extra : source : af07351bf2d6e85293ae3edf0fe4ae6cbc0ce246
This reworks how the Mochitest DOMWINDOW and DOCSHELL leak detector works. Rather than
collecting immediately in the top-level script, it sends a message to all processes
telling them to carry out collections. Each process prints out a message when it has
finished the collections. This message is used by the test harness to decide when windows
and docshells for that process should be have been destroyed.
In non-e10s mode, the shutdown leak detector is only run in the parent process, to work
around various issues with leak detection in the thumbnail process tests.
This reworks how the Mochitest DOMWINDOW and DOCSHELL leak detector works. Rather than
collecting immediately in the top-level script, it sends a message to all processes
telling them to carry out collections. Each process prints out a message when it has
finished the collections. This message is used by the test harness to decide when windows
and docshells for that process should be have been destroyed.
It looks like overwriting AS here is not intentional. Before this patch,
it is impossible to override AS through mozconfig for anything that runs
past this stage in configure.
It turns out that while it may have been needed at the time it was added (which,
retrospectively, I'm not even sure was the case), it definitely isn't needed
anymore.
Some Android SDK installations do not have the zipalign program in
the same directory as other Android build tools. For example,
zipalign may be found in /build-tools/21.1.2 whereas the
rest of the build tools are in /build-tools/android-4.4.
I think these undefined variables don't matter because it's a static analysis
input, but defining them does stop cppcheck from complaining.
--HG--
extra : rebase_source : 9f663aad5c939af6798cb9a080d25256c3d105fe
Right now, if the LLVMCONFIG variable is not set in the .mozconfig, we
first look for the system default llvm-config and only then we ask clang
itself, which breaks building with the clang plugin if you make $CC and
$CXX point to a non-default clang binary. This patch fixes the issue
by reversing the search order.
--HG--
extra : rebase_source : 23ab716f4e220097e4c31092475dba769f4e7dfc
Now that defining $DMD is no longer necessary to run DMD, this patch does the
following.
- Removes all the places where we set DMD=1 (test harnesses, etc.)
- Still handles DMD=1, for backwards compatibility.
- Prints "$DMD is undefined" at DMD start-up if appropriate.
- Writes a |null| value for |dmdEnvVar| in the JSON if $DMD is undefined. Bumps
the DMD output version number accordingly.
- Changes a bunch of the test files accordingly, including changing the mode of
script-ignore-alloc-fns.json in order to test a case where $DMD is undefined.
--HG--
extra : rebase_source : eb1ef5722410734ce6d7658465ff6f442ee4ed49
Mike Hommey
Ehsan Akhgari
Wes Kocher
Alexandre Poirot
Makoto Kato
Ryan VanderMeulen
Jacek Caban
ijdt.editor@gmail.com
Ben Turner
Ted Mielczarek
Victor Porof
Hector Zhao
L. David Baron
Axel Hecht
Jim Blandy
Mike Shal
Bob Owen
Carsten "Tomcat" Book
Bhargav Chippada
Chris Manchester
Gregory Szorc
Anish
Nigel Babu
Tooru Fujisawa
David Burns
Nathan Froyd
Andrew McCreight
Kevin K.
Andrew McCreight
Phil Ringnalda
Randell Jesup
Brian Smith
James Lal
Akos Kiss
Abhishek Bhattacharya
Nikhil Marathe
Richard Newman
Masatoshi Kimura
Trevor Saunders
Jim Chen
Dave Hylands
Nicholas Nethercote
Mark Goodwin
Ms2ger
Prashant Baisla
R Kent James
Jed Davis
Tom Tromey
Andrew Halberstadt