XPIDL generated header files contain a |#if 0| block for every interface,
providing the skeleton of the class as it must be implemented in C++. This is
potentially useful, but also very verbose.
This patch removes this code. In a Linux64 debug build, this reduces the total
size of the $OBJDIR/dist/include/nsI*.h files from 11,023,499 bytes to
8,442,350 bytes, a 23.5% reduction. It didn't speed up compilation, though.
--HG--
extra : rebase_source : 65e1e46cffe7c831d83c3308d7ce58c801618dda
This moves AboutNewTab.init from nsBrowserGlue.js handling of "browser-delayed-startup-finished" into aboutNewTabService.js so that when the service is loaded once from the main thread probably by browser.js towards the beginning of _delayedStartup just before potentially calling gBrowser.loadTabs, the service triggers the attaching of RemotePages(about:newtab) before any about:newtab pages load.
Additionally even when RemotePages starts early enough, Activity Stream might not borrow the RemotePages instance early enough to catch the RemotePage:Load message, so to simulate that, RemotePages now remembers when a port has been loaded for consumers to check. Adds tests to confirm the expected properties on the port and value of loaded at the various RemotePage:* messages.
MozReview-Commit-ID: IXJLvFCgbEH
--HG--
extra : rebase_source : 2b53c4e58f4cb8cbd4ea10741f3f609693989010
The lesson learned from bug 1356926 and bug 1386588 is that the version
of gcc used to build clang matters, and that we can't bind the version
we use to build clang to the version we use to build Firefox.
In some cases, we can end up linking some things with
--static-libstdc++. The notable (only?) example of that is for the
clang-plugin, and that happens because it gets some of its flags from
llvm-config, which contains --static-libstdc++ because clang itself is
built that way.
When that happens, the combination of --static-libstdc++ and
stdc++compat breaks the build because they have conflicting symbols,
which is very much by design.
There are two ways out of this:
- avoiding either -static-libstdc++ or stdc++compat
- work around the symbol conflicts
The former is not totally reliable ; we'd have to accurately determine
if we're in a potentially conflicting case, and remove one of the two in
that case, and while we can do that for the cases we explicitly know
about, that's not future-proof, and might fail just as much in the
future.
So we go with the latter. The way we do this is by defining all the
std++compat symbols weak, such that at link time, they're overridden by
any symbol with the same name. When building with -static-libstdc++,
libstdc++.a provides those symbols so the linker eliminates the weak
ones. When not building with -static-libstdc++, the linker keeps the
symbols from stdc++compat. That last assertion is validated by the
long-standing CHECK_STDCXX test that we run when linking shared
libraries and programs.
That still leaves the symbols weak in the final shared
libraries/programs, which is a change from the current setup, but
shouldn't cause problems because when using versions of libstdc++.so
that do provide those symbols, it's fine to use the libstdc++.so version
anyways.
This method can be extremely hot, so we need to remove all sources of XPCOM
overhead from it. This includes the usages of weak pointers (thanks to the
previous parts), refcounting, and QueryInterface.
I kept the callers hold the selection controller alive by assigning the
return value to an nsCOMPtr in places where the methods called on it could
have a remote chance of messing with the lifetime of objects.
We need to create a WebRenderAnimationData item in order to preserve the
animation id on the frame - this allows to re-use the same animation id
over multiple display list building phases.
MozReview-Commit-ID: 5Uj5sv6FUgt