Re: Triage for Component Leads

The wiki says everything from July 1 onwards should be triaged, but the triage-center tool produces bugzilla links from June 1 onwards (when you select the "no priority decision" link). Is this intentional, or just a mix-up? On Thu, Jun 16, 2016 at 5:17 PM, Emma Humphries

Re: Return-value-optimization when return type is RefPtr

On 05/24/2016 08:33 AM, jww...@mozilla.com wrote: For RefPtr GetFoo() { RefPtr foo; // ... } should we: 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release 2. return foo.forget() 3. return Move(foo) Which one is preferred? ps: I find gcc is able to apply RVO

Triage for Component Leads

This afternoon I introduced the new triage process we've developed for bugs in Firefox-related components. My presentation is at https://docs.google.com/presentation/d/1qlXlDsMnvcpA5ppJVJWIBaBDPEyw5hbjU-Q7wjjrZQM/edit?usp=sharing The guide to the process is on the Mozilla wiki:

Re: Return-value-optimization when return type is RefPtr

On Thu, Jun 16, 2016 at 2:15 PM, Michael Layzell wrote: > We pass T* as an argument to a function too often for this to e practical. > Can you explain why? Is your point here to avoid people having to type .get() or the mass conversion from the current code? The former

Re: Return-value-optimization when return type is RefPtr

We pass T* as an argument to a function too often for this to e practical. The best solution is probably to remove the conversion from RefPtr&& to T* which is I believe what froydnj is planning to do. This requires ref qualifiers for methods, which isn't supported in MSVC 2013, but is supported

Re: Nightly Only Containers Feature

Looks like there are some formatting issues with the blogpost link, so sending it again: https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/ On 6/16/16 11:42 AM, Tanvi Vyas wrote: This week we enabled the Containers feature for testing in Nightly. Containers is a way

Re: Return-value-optimization when return type is RefPtr

Is it worth reconsidering removing implicit conversion from RefPtr to T*? -Ekr On Thu, Jun 16, 2016 at 9:50 AM, Boris Zbarsky wrote: > On 6/16/16 3:15 AM, jww...@mozilla.com wrote: > >> I think that is the legacy when we don't have move semantics. Returning >> RefPtr won't

Nightly Only Containers Feature

This week we enabled the Containers feature for testing in Nightly. Containers is a way for users to have multiple browsing contexts within the sameprofile. With these different contexts, Containersallows users to login to multiple accounts on the same domain simultaneouslyin the same browser

Re: Return-value-optimization when return type is RefPtr

On 6/16/16 3:15 AM, jww...@mozilla.com wrote: I think that is the legacy when we don't have move semantics. Returning RefPtr won't incur ref-counting overhead and is more expressive and functional. Except for the footgun described in

Re: Return-value-optimization when return type is RefPtr

Coincidentally: (?) https://bugzilla.mozilla.org/show_bug.cgi?id=1280296 "remove already_AddRefed" :-) For your original question, I would vote for RVO when possible, and Move() otherwise. It feels like static analysis should be able to detect cases where RVO is possible and suggest it if