Re: Stop #including jsapi.h everywhere!

On 9/7/13 9:43 PM, Nicholas Nethercote wrote: One possibility is to move them into their own header(s) in js/public/ That would work, yes. Another is to heap-allocate them This has somewhat undesirable performance implications, not to mention the general weirdness of heap-allocating RAII

Re: Stop #including jsapi.h everywhere!

On Sun, Sep 8, 2013 at 11:02 AM, Boris Zbarsky wrote: > > I believe nsCxPusher.h only needs jsapi.h because it needs to know > sizeof(JSAutoRequest) and sizeof(JSAutoCompartment) for the members of > AutoCxPusher... Not sure what we can do with that. One possibility is to move them into their ow

Re: Stop #including jsapi.h everywhere!

On 9/7/13 8:49 PM, Nicholas Nethercote wrote: I've been focusing entirely on jsapi.h includes. We're down to ~1480 rebuilt files when it gets touched; we started at ~2600. It's getting hard to improve, because there's a tangled clump of widely-included files that include it still either direct

Re: Stop #including jsapi.h everywhere!

On Sun, Sep 8, 2013 at 2:38 AM, Benoit Jacob wrote: > I just was starting to look at BindingUtils.h as it is one of the most > important "hub headers" that we have (see > https://bugzilla.mozilla.org/show_bug.cgi?id=912735). But it seems that you > guys are already well ahead into BindingUtils.h d

Re: Stop #including jsapi.h everywhere!

2013/9/7 Benoit Jacob > > > > 2013/9/7 Boris Zbarsky > > >> >> This is good, but unfortunately leaks in all over the place >> anyway in DOM code. >> >> The way it does that is that dom/Element.h has inline methods that need >> nsPresContext.h and Units.h. Either one will get you things like ns

Re: Stop #including jsapi.h everywhere!

2013/9/7 Boris Zbarsky > On 9/7/13 12:56 PM, Benoit Jacob wrote: > >> https://bugzilla.mozilla.org/**show_bug.cgi?id=913847 >> moves NS_IsMainThread >> to a new MainThreadUtils.h header that's cheaper to include, and in >> particular is all wh

Re: Stop #including jsapi.h everywhere!

On 9/7/13 12:56 PM, Benoit Jacob wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=913847 moves NS_IsMainThread to a new MainThreadUtils.h header that's cheaper to include, and in particular is all what BindingUtils.h needs (there was a helpful comment about that in BindingUtils.h). Excellen

Re: Stop #including jsapi.h everywhere!

2013/9/7 Benoit Jacob > I just was starting to look at BindingUtils.h as it is one of the most > important "hub headers" that we have (see > https://bugzilla.mozilla.org/show_bug.cgi?id=912735). But it seems that > you guys are already well ahead into BindingUtils.h discussion. Is there a > bug f

Re: Stop #including jsapi.h everywhere!

I just was starting to look at BindingUtils.h as it is one of the most important "hub headers" that we have (see https://bugzilla.mozilla.org/show_bug.cgi?id=912735). But it seems that you guys are already well ahead into BindingUtils.h discussion. Is there a bug filed for it? Benoit 2013/8/21 N

Re: Stop #including jsapi.h everywhere!

On Wed, Aug 21, 2013 at 4:46 PM, Boris Zbarsky wrote: > On 8/21/13 2:23 AM, Nicholas Nethercote wrote: >> >> And jswrapper.h includes jsapi.h. I will try to remedy that... it looks doable. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.o

Re: Stop #including jsapi.h everywhere!

On 8/21/13 2:23 AM, Nicholas Nethercote wrote: It tells me that BindingUtils.h is responsible for 824 inclusions of jswrapper.h during a build. And jswrapper.h includes jsapi.h. It needs jswrapper.h for js::IsWrapper and js::CheckedUnwrap. And the part of it that needs those is used by every

Re: Stop #including jsapi.h everywhere!

On Tue, Aug 20, 2013 at 9:01 AM, Boris Zbarsky wrote: > > BindingUtils.h we could try breaking up in various ways, but it should be > very rare for _headers_ to include that file; for the most part such > inclusions are a bug from my point of view. For non-headers that include it > (e.g. binding

Re: Stop #including jsapi.h everywhere!

On Tue, Aug 20, 2013 at 11:19 AM, Jeff Walden wrote: > On 08/20/2013 09:01 AM, Boris Zbarsky wrote: >> DOMJSClass.h only needs various forward-declarations, mostly. The >> exceptions are: >> >> 2) It needs the definition of JSClass, for a member of the DOMJSClass >> struct and the DOMIfaceAndP

Re: Stop #including jsapi.h everywhere!

On 2013-08-20 12:52 PM, Gregory Szorc wrote: In order to do that we would basically need to build a bug-free include-what-you-use, and AFAIK nobody has signed up to do that work. Also note that such a check will only be useful if we adhere to the principle of using forward-decls where possible th

Re: Stop #including jsapi.h everywhere!

On 08/20/2013 09:01 AM, Boris Zbarsky wrote: > DOMJSClass.h only needs various forward-declarations, mostly. The exceptions > are: > > 2) It needs the definition of JSClass, for a member of the DOMJSClass struct > and the DOMIfaceAndProtoJSClass struct. Unfortunately, this is defined in > js

Re: Stop #including jsapi.h everywhere!

On 8/20/13 7:27 AM, Ehsan Akhgari wrote: On 2013-08-19 9:10 PM, Gregory Szorc wrote: On 8/19/13 5:15 PM, Nicholas Nethercote wrote: Hi, Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has indicated that jsapi.h is probably responsible for more recompilation than any other file

Re: Stop #including jsapi.h everywhere!

On 8/19/13 8:15 PM, Nicholas Nethercote wrote: Unfortunately, this work will only go so far because xpcpublic.h, BindingUtils.h, and DOMJSClass.h all (unavoidably) include jsapi.h, and they are headers that are large and included in lots of places. I'd love to hear suggestions as to how they cou

Re: Stop #including jsapi.h everywhere!

On 2013-08-19 9:10 PM, Gregory Szorc wrote: On 8/19/13 5:15 PM, Nicholas Nethercote wrote: Hi, Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has indicated that jsapi.h is probably responsible for more recompilation than any other file in the Mozilla tree -- it gets included in

Re: Stop #including jsapi.h everywhere!

On 08/20/2013 02:15 AM, Nicholas Nethercote wrote: They can be replaced by forward declarations of a handful of types, e.g.: struct jsid; This is not actually the case: jsid is a typedef for ptrdiff_t in release builds, so you'll still need to include jspubtd.h for it. HTH Ms2ger ___

Re: Stop #including jsapi.h everywhere!

> namespace JS { > class Value; // #include js/Value.h (not jsapi.h) if you need the > *definition* > } Oh, and avoid |jsval| -- it's on the way out, and is just a typedef for JS::Value, which should be used instead. Nick ___ dev-platform mailing

Re: Stop #including jsapi.h everywhere!

On 8/19/13 5:15 PM, Nicholas Nethercote wrote: Hi, Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has indicated that jsapi.h is probably responsible for more recompilation than any other file in the Mozilla tree -- it gets included in *lots* of files, and it gets modified very o

Re: Stop #including jsapi.h everywhere!

> Next time you're thinking of adding a |#include "jsapi.h"| statement, > please think about whether a forward declaration would suffice I forgot to mention that as well as within .h files, this can also be done in .idl files, in the |%{ C++ %}| section. Nick _

Re: Stop #including jsapi.h everywhere!

On Mon, Aug 19, 2013 at 05:15:13PM -0700, Nicholas Nethercote wrote: > Hi, > > Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has > indicated that jsapi.h is probably responsible for more recompilation > than any other file in the Mozilla tree -- it gets included in *lots* > of fi

Stop #including jsapi.h everywhere!

Hi, Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has indicated that jsapi.h is probably responsible for more recompilation than any other file in the Mozilla tree -- it gets included in *lots* of files, and it gets modified very often, partly because it's so large. (jsfriendapi