This matters when a [Cached] attribute appears on an interface, call it C,
which is a consequential interface for both A and B. There is no a priori
reason that A and B would have identical numbers of their own [Cached]
attributes, which will come before the members of consequential interfaces in
the member array, so in general the attribute may have different slot indices in A
and B.
The approach taken here is to keep things simple and make the slot index of an
interface member either None or a dict mapping interface name to the slot
index. In the common case of only one interface being involved this is a
little wasteful, but it keeps things simple for consumers, and one extra dict
per [Cached] attribute is not a big deal in the grand scheme of the data
structures the Web IDL parser produces. Another option would be to store None,
a number (if there is only one interface involved), or a dict (if there are
several interfaces involved). If we did that, we'd probably want to add some
method to get the slot index for a given interface, because the logic for doing
that would get a bit more complicated.
nsWrapperCache expects the object it stores to have an ObjectMoved op that will
notify the wrapper cache when the object is moved. SpiderMonkey promises don't
have a way to do this.
The XPCConvert changes are needed to allow code that passes around Promise
objects as nsISupports to continue working instead of ending up with
double-wrapped nsISupports (XPCWrappedNative for an nsISupports XPCWrappedJS)
around the SpiderMonkey Promise.
This patch introduces a fake IDL interface just to get the benefits of
cycle collection for the JS-to-C++ link we now need for PromiseNativeHandler
(because the SpiderMonkey Promise somehow needs to point to the
PromiseNativeHandler). Now in practice a bunch of our PromiseNativeHandlers
are not cycle collected. That kinda freaks me out, but spot-checking a few
suggests they do not in fact leak (either because they don't form cycles or
because the Promise they're observing always settles and then releases them).
Either way, that's a problem that exists with or without this patch...
The idea is to not define a "Promise" property on the global and not generate
any of the methods, since SpiderMonkey will implement all of those, but to keep
some of the conversion to/from JS logic and the IDL parser validation bits that
we have right now. Once we can assume SPIDERMONKEY_PROMISE we can probably
change how the "Promise" identifier is handled by the IDL parser and how the
resulting type is handled by codegen, but for now we're aiming for minimal
changes.
The output of WebIDL codegen is a bunch of .h and .cpp files. These
aren't relevant when not compiling.
This change appears to shave ~3-4s off the "export" tier time for
--disable-compile-environment builds on my i7-6700K because WebIDL
codegen is currently a long pole in that tier. After this patch,
artifact clobber builds are ~43.5s.
