The FileExists check can be removed because the code loading the library
will handle that case already.
--HG--
extra : rebase_source : bac53d3f88ed1dd716ee1340d40dae42becdfdf0
Now that nothing is using those functions, we can remove them and limit
the scope of the standalone glue to initialize the new Bootstrap API.
--HG--
extra : rebase_source : b73845a207f8d6e632c46d089a00b7a67e1648fc
Here, we also modify APKOpen to use the XPCOM glue loading process
instead of custom symbol resolution, so that the Bootstrap API can be
used in a more straightforward manner.
--HG--
extra : rebase_source : 55037ba30ca66a090b73923a3ce8df5b054bf47a
This is the first step towards changing how nsBrowserApp and other current
XPCOM glue users start up Gecko.
The goal here is to expose the same API via a single object with a
VTable instead of the current XPCOM glue machinery. Instead of creating
an entirely new API and changing everything to use it, we go forward
with smaller steps for a more comprehensible transition.
--HG--
extra : rebase_source : c2cf90ab3bb812b9ea75c70c9766f1a47ea50828
Back in bug 632404, when the function was added, preloading was
conditional. But after some A/B testing, the conclusion in bug 771745
was that we would just do preloading unconditionally.
Which means in practice, we don't need to have a function to enable it
manually anymore, since we're always enabling it.
--HG--
extra : rebase_source : c76307c13c057e87e1fe4564b82113fbfa20d382
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
--HG--
extra : source : 6bf72b4eaa92b13d42b547d8aeee677489a4d3e2
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
--HG--
extra : source : 47cd2c22bafc8d4bb1c7e1dce3b45517aaec199f
This class can be used instead of raw pointer for a sound leaking-by-default
behavior. Also it could take advantage of move semantic check in the future.
--HG--
extra : source : 3dbd000739dc0ea214a2292e3983469e41e99686
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.
The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.
Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.
The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.
Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
We build without UNICODE, so we end up calling the ANSI version
of the function, and then we would attempt to interpret the
resulting narrow char buffer as a wide char buffer.
Currently, when there is both an expandlibs descriptor and an actual static
library, expandlibs picks the static library. This has the side effect that
if there are object files in the static library that aren't directly used,
they're dropped when linking, even when they export symbols that would be
exported in the final linked binary.
In most cases in the code base, files are not dropped that way. The most
notable counter-example is xpcomglue, where actually not dropping files
leads to link failure because of missing symbols those files reference
(yes, that would tend to say the glue is broken in some way).
On the opposite side, there is mozglue, which does have both a descriptor
and a static library (the latter being necessary for the SDK), and that
linking as a static library drops files that shouldn't be dropped (like
jemalloc). We're currently relying on -Wl,--whole-archive for those files
not to be dropped, but that won't really be possible without much hassle
in a world where mozglue dependencies live in moz.build land.
Switching expandlibs to use descriptors when they exist, even when there
is a static library (so, the opposite of the current behavior) allows to
drop -Wl,--whole-archive and prepare for a better future. However, as
mentioned, xpcomglue does still require to be linked through the static
library, so we need to make it a static library only.
To achieve that, we make NO_EXPAND_LIBS now actually mean no expandlibs
and use that to build the various different xpcomglues.