This also disables a couple of tests that depend on the network
provider on Android. These tests were passing by accident before
this patch (and started failing afterwards), and were never meant
to run on Android anyway.
Generally, if you want a decltype(nullptr)-based overload, you should use SFINAE and IsNullPointer. (Examples are provided in NullPtr.h comments.) The problem is NullptrT matches far more than just __null as emulated nullptr for gcc 4.4/4.5 overloading purposes. This problem is unavoidable without true nullptr. Currently, the only valid use for NullptrT is believed to be in operator overloads. All existing nullptr-overloading code has been rewritten to use the appropriate technique for the situation, and MOZ_HAVE_CXX11_NULLPTR is no longer an API.
--HG--
extra : rebase_source : 01abfcb66ae569db7b04a7b53f5cd5fd8151bffd
For register-rich ABIs (e.g. x86-64 and ARM), QueryInterface's incoming
registers are going to look like:
arg register 1: |this|
arg register 2: the IID of interest
arg register 3: the outparam instance pointer
Most of our QI implementations call NS_TableDrivenQI, which expects
arguments like so:
arg register 1: |this|
arg register 2: the QITableEntry table
arg register 3: the IID of interest
arg register 4: the outparam instance pointer
So we're going to have to do a register shuffle of the IID and the
outparam to be able to load the QITableEntry pointer before calling into
NS_TableDrivenQI.
This patch reorders the argument list of NS_TableDrivenQI so that the
first three arguments match the order that QueryInterface receives them
in. Then your typical QueryInterface implementation becomes:
- load local |table|
- tail-call NS_TableDrivenQI
Eliminating the register shuffling reduces text size by 12K on an
Android ARM build.
Due to graph mutation during an incremental cycle collection, objects in the CC graph
may end up with more things pointing to them than they have a ref count. However, these
objects should never become garbage.
Any object that has been stored away somewhere in the middle of incremental graph
building must be treated as live, because we can't trust that the CC graph has
accurate information about it. If such an object is truly garbage, we'll unlink it
in the next cycle collection instead.
ICC uses this to track objects that have been AddRef'd during ICC graph building.
For those objects, we may not have the proper information for them, so treat them
as live.
Due to graph mutation during an incremental cycle collection, objects in the CC graph
may end up with more things pointing to them than they have a ref count. However, these
objects should never become garbage.
Any object that has been stored away somewhere in the middle of incremental graph
building must be treated as live, because we can't trust that the CC graph has
accurate information about it. If such an object is truly garbage, we'll unlink it
in the next cycle collection instead.
ICC uses this to track objects that have been AddRef'd during ICC graph building.
For those objects, we may not have the proper information for them, so treat them
as live.
