Each one of these uses grabs the principal off of an object for pushing, but also enters the compartment of that object. So we shouldn't need this anymore.
Can I get a 'hell yeah'?
A common source of potential black -> gray edges is JSAPI calls made on objects with gray globals or contexts holding gray globals. (The call could potentially update a black object with a pointer to that global.) This patch mostly traps places where contexts are used, and unmarks their globals. It also includes some more global unmarking.
--HG--
extra : rebase_source : 835c1d6b4a7f7a11571412075ae8847475079edd
A common source of potential black -> gray edges is JSAPI calls made on objects with gray globals or contexts holding gray globals. (The call could potentially update a black object with a pointer to that global.) This patch mostly traps places where contexts are used, and unmarks their globals. It also includes some more global unmarking.
--HG--
extra : rebase_source : 1286bdbc4c337956242c292e0fa385629ee8850b
In the new setup, all per-interface DOM binding files are exported into
mozilla/dom. General files not specific to an interface are also exported into
mozilla/dom.
In terms of namespaces, most things now live in mozilla::dom. Each interface
Foo that has generated code has a mozilla::dom::FooBinding namespace for said
generated code (and possibly a mozilla::bindings::FooBinding_workers if there's
separate codegen for workers).
IDL enums are a bit weird: since the name of the enum and the names of its
entries all end up in the same namespace, we still generate a C++ namespace
with the name of the IDL enum type with "Values" appended to it, with a
::valuelist inside for the actual C++ enum. We then typedef
EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to
refer to the values, but means that values from different enums don't collide
with each other.
The enums with the proto and constructor IDs in them now live under the
mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively.
Again, this lets us deal sanely with the whole "enum value names are flattened
into the namespace the enum is in" deal.
The main benefit of this setup (and the reason "Binding" got appended to the
per-interface namespaces) is that this way "using mozilla::dom" should Just
Work for consumers and still allow C++ code to sanely use the IDL interface
names for concrete classes, which is fairly desirable.
--HG--
rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp
rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
