Including just to get std::min and std::max

Hi, It seems that we have some much-included header files including just to get std::min and std::max. That seems like an extreme case of low ratio between lines of code included (9,290 on my system, see Appendix below) and lines of code actually used (say 6 with whitespace). I ran into this is

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

Creating mock nsIPrintingPromptService

(Apologies if this is not the right forum, in which case please direct me to one). I am looking at creating a mock nsIPrintingPromptService (so that I can bring up my own Print dialog) for my testing purpose, preferably in Javascript. I looked around Mozilla code base but couldn't find a starti

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