Re: std::unique_ptr, std::move,

2013-08-07 Thread Ehsan Akhgari
On Fri, Aug 2, 2013 at 9:11 PM, Brian Smith wrote: > On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari wrote: > >> On 2013-08-02 4:49 PM, Brian Smith wrote: >> >>> That sounds reasonable to me. So, based on that then, let's get back to >>> my >>> original question that motivated the discussion of th

Re: std::unique_ptr, std::move,

2013-08-07 Thread Ehsan Akhgari
On Fri, Aug 2, 2013 at 11:02 PM, Mike Hommey wrote: > On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote: > > On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari >wrote: > > > > > This adds too much risk of security patches failing to backport from > > > > > >> mozilla-central to ESR 24. Rem

Re: std::unique_ptr, std::move,

2013-08-02 Thread Mike Hommey
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote: > On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari wrote: > > > This adds too much risk of security patches failing to backport from > > > >> mozilla-central to ESR 24. Remember that one of the design goals of ESR > >> is to minimize the a

Re: std::unique_ptr, std::move,

2013-08-02 Thread Brian Smith
On Sat, Aug 3, 2013 at 12:50 AM, Ehsan Akhgari wrote: > On 2013-08-02 4:49 PM, Brian Smith wrote: > >> That sounds reasonable to me. So, based on that then, let's get back to my >> original question that motivated the discussion of the policy: If we add >> std::move, std::forward, and std::unique_

Re: std::unique_ptr, std::move,

2013-08-02 Thread Boris Zbarsky
On 8/2/13 8:14 PM, Brian Smith wrote: The risk that any developer would need to waste time on ESR just to support a product that isn't even Firefox on a platform that virtually nobody uses, and the risk that comes with making any changes to the security fix that you are trying to backport. I fe

Re: std::unique_ptr, std::move,

2013-08-02 Thread Brian Smith
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari wrote: > This adds too much risk of security patches failing to backport from > >> mozilla-central to ESR 24. Remember that one of the design goals of ESR >> is to minimize the amount of effort we put into it so that ESR doesn't >> slow down real Fire

Re: std::unique_ptr, std::move,

2013-08-02 Thread Neil
Brian Smith wrote: We have mozilla-build for Windows. From what you say, it sounds like we should have mozilla-build for Linux too that would include a pre-built GCC or Clang or whatever we choose as *the* toolchain for desktop Linux. mozilla-build doesn't include a compiler or SDK. At one po

Re: std::unique_ptr, std::move,

2013-08-02 Thread Ehsan Akhgari
On 2013-08-02 4:39 PM, Brian Smith wrote: On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey mailto:m...@glandium.org>> wrote: > Upgrading minimum compiler requirements doesn't imply backporting those > requirements to Aurora where ESR24 is right now. Are you opposed to > updating o

Re: std::unique_ptr, std::move,

2013-08-02 Thread Ehsan Akhgari
On 2013-08-02 4:49 PM, Brian Smith wrote: That sounds reasonable to me. So, based on that then, let's get back to my original question that motivated the discussion of the policy: If we add std::move, std::forward, and std::unique_ptr to STLPort for Android and B2G, can we start using std::move,

Re: std::unique_ptr, std::move,

2013-08-02 Thread Brian Smith
On Fri, Aug 2, 2013 at 1:36 AM, Joshua Cranmer 🐧 wrote: > On 8/1/2013 5:46 PM, Brian Smith wrote: > >> FWIW, I talked about this issue with a group of ~10 Mozillians here in >> Berlin and all of them (AFAICT) were in favor of requiring that the latest >> versions of GCC be used, or even dropping G

Re: std::unique_ptr, std::move,

2013-08-02 Thread Brian Smith
On Fri, Aug 2, 2013 at 2:58 PM, Mike Hommey wrote: > > Upgrading minimum compiler requirements doesn't imply backporting those > > requirements to Aurora where ESR24 is right now. Are you opposed to > > updating our minimum supported gcc to 4.7 on trunk when Firefox OS is > ready > > to switch?

Re: std::unique_ptr, std::move,

2013-08-02 Thread Mike Hommey
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote: > On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey wrote: > > > On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote: > > > Debian doesn't keep Iceweasel up to date in oldstable anyway. > > > > Actually, I'm providing backports for

Re: std::unique_ptr, std::move,

2013-08-02 Thread Ehsan Akhgari
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey wrote: > On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote: > > Debian doesn't keep Iceweasel up to date in oldstable anyway. > > Actually, I'm providing backports for oldstable. 24 is as far as I'm > ready to go to support oldstable until it

Re: std::unique_ptr, std::move,

2013-08-01 Thread Mike Hommey
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote: > Debian doesn't keep Iceweasel up to date in oldstable anyway. Actually, I'm providing backports for oldstable. 24 is as far as I'm ready to go to support oldstable until its actual EOL next year. Which is why i want ESR24 to remain co

Re: std::unique_ptr, std::move,

2013-08-01 Thread Joshua Cranmer 🐧
On 8/1/2013 5:46 PM, Brian Smith wrote: FWIW, I talked about this issue with a group of ~10 Mozillians here in Berlin and all of them (AFAICT) were in favor of requiring that the latest versions of GCC be used, or even dropping GCC support completely in favor of clang, if it means that we can use

Re: std::unique_ptr, std::move,

2013-08-01 Thread Matt Brubeck
On 7/31/2013 4:06 AM, Brian Smith wrote: On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote: I strongly oppose to any requirement that would make ESR+2 (ESR31) not build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not build on the old Debian stable (gcc 4.4). We're not going

Re: std::unique_ptr, std::move,

2013-08-01 Thread Brian Smith
On Wed, Jul 31, 2013 at 8:09 PM, Joshua Cranmer 🐧 wrote: > > More generally, nobody should be reasonably expected to write code that >> builds with any combination that isn't used on mozilla-central's TBPL. So, >> (clang, MSVC) is not really something to consider, for example. >> > > clang + MSVC

Re: std::unique_ptr, std::move,

2013-08-01 Thread Brian Smith
On Wed, Jul 31, 2013 at 2:19 PM, Mike Hommey wrote: > On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote: > > On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote: > > > > > I strongly oppose to any requirement that would make ESR+2 (ESR31) > > > not build on the current Debian stable (g

Re: std::unique_ptr, std::move,

2013-08-01 Thread Jeff Walden
On 07/31/2013 01:25 AM, Brian Smith wrote: > Anyway, it would be easier to swallow the dependency on MFBT if it wasn't > so large (over 100 files now), if it tried to be (just) a polyfill for > missing standard library features, and if it could easily be used > independently of the Gecko build syst

Re: std::unique_ptr, std::move,

2013-07-31 Thread Joshua Cranmer 🐧
ction compilers until 2014 at the earliest. Basically, I'm proposing that we add std::unique_ptr, std::move, std::forward, and some nulllptr polyfill to STLPort with the intention that we can assume these features work. That is, if some (compiler, standard library) combination doesn't ha

Re: std::unique_ptr, std::move,

2013-07-31 Thread Mike Hommey
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote: > On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote: > > > I strongly oppose to any requirement that would make ESR+2 (ESR31) > > not build on the current Debian stable (gcc 4.7) and make ESR+1 > > (ESR24) not build on the old Debian

Re: std::unique_ptr, std::move,

2013-07-31 Thread Brian Smith
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote: > I strongly oppose to any requirement that would make ESR+2 (ESR31) not > build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not > build on the old Debian stable (gcc 4.4). We're not going to change the > requirements for the

Re: std::unique_ptr, std::move,

2013-07-31 Thread Mike Hommey
On Wed, Jul 31, 2013 at 10:25:15AM +0200, Brian Smith wrote: > We should be more aggressive in requiring newer compiler versions > whenever practical, and we should choose to support as few > compiler/library combinations as we can get away with. That way we can > use as many C++11/14 features (not

Re: std::unique_ptr, std::move,

2013-07-31 Thread Brian Smith
issue, but it would not be rolled out to production > compilers until 2014 at the earliest. > Basically, I'm proposing that we add std::unique_ptr, std::move, std::forward, and some nulllptr polyfill to STLPort with the intention that we can assume these features work. That is, if some

Re: std::unique_ptr, std::move,

2013-07-30 Thread Joshua Cranmer 🐧
On 7/30/2013 10:39 PM, Brian Smith wrote: On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari wrote: On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote: But, shouldn't we just name these std::move and std::forward and use these implementations only when we're using STLPort? I know we're not suppos

Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

2013-07-30 Thread Brian Smith
On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari wrote: > On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote: > >> But, shouldn't we just name these std::move and std::forward and use these >> implementations only when we're using STLPort? I know we're not supposed >> to >> add stuff to the std:: na

Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

2013-07-30 Thread Mike Hommey
On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote: > On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith > wrote: > > > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey > > wrote: > > > > > Note that STL is another story. We're not using libstdc++ that > > > comes with the compiler on android a

Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

2013-07-30 Thread Ehsan Akhgari
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote: > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey wrote: > > > Note that STL is another story. We're not using libstdc++ that comes > > with the compiler on android and b2g. We use STLport instead, and STLport > > has, afaik, no support for C++11

std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

2013-07-30 Thread Brian Smith
On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey wrote: > Note that STL is another story. We're not using libstdc++ that comes > with the compiler on android and b2g. We use STLport instead, and STLport > has, afaik, no support for C++11 STL types. So, while we can now fix > nsAutoPtr to use move sem