Sharing string literals

2014-01-09 Thread Neil
Until today Gecko's support for string constants was quite poor. You could create a literal string or a named literal string on the stack and pass it to a method but any operation on the string ended up copying the string. In effect a literal string was a dependent string whose length was known

Target Milestone field in bugzilla

2014-01-09 Thread Kartikaya Gupta
I think the "Target Milestone" field is poorly named, at least with respect to what we use it for. In practice this field is set to the version of m-c on which the patches originally landed, and doesn't change when patches are uplifted to other branches. However, I've seen many people mistake

Re: Style guide clarity on C++-isms

2014-01-09 Thread Milan Sreckovic
if the goal of the styles is the readability, do we know that people actually care which one of the described approaches we use, or is it also the "look, not all of these things are the same" that offends us? For example, I find the consistency of the positioning of {} for the loops and conditi

Re: Style guide clarity on C++-isms

2014-01-09 Thread Martin Thomson
On 2014-01-09, at 08:48, Milan Sreckovic wrote: > For example, I find the consistency of the positioning of {} for the loops > and conditionals extremely important for readability. Outside of any real extremes, I’ve found that consistency is far more important than any personal preferences.

Re: Target Milestone field in bugzilla

2014-01-09 Thread Gavin Sharp
(It's probably a good idea scope this discussion to common practice in the "Firefox" components i.e. Core/Firefox/Toolkit/etc. Bugzilla discussions like this one can get into the weeds pretty quickly when people bring up other projects who use our Bugzilla installation and who have different practi

Re: Target Milestone field in bugzilla

2014-01-09 Thread Chris Peterson
On 1/9/14, 7:17 AM, Kartikaya Gupta wrote: I think the "Target Milestone" field is poorly named, at least with respect to what we use it for. In practice this field is set to the version of m-c on which the patches originally landed, and doesn't change when patches are uplifted to other branches.

Re: Target Milestone field in bugzilla

2014-01-09 Thread Dave Townsend
On Thu, Jan 9, 2014 at 9:53 AM, Chris Peterson wrote: > On 1/9/14, 7:17 AM, Kartikaya Gupta wrote: > >> I think the "Target Milestone" field is poorly named, at least with >> respect to what we use it for. In practice this field is set to the >> version of m-c on which the patches originally lande

Re: Target Milestone field in bugzilla

2014-01-09 Thread Chris Hofmann
On 1/9/14 9:53 AM, Chris Peterson wrote: On 1/9/14, 7:17 AM, Kartikaya Gupta wrote: I think the "Target Milestone" field is poorly named, at least with respect to what we use it for. In practice this field is set to the version of m-c on which the patches originally landed, and doesn't change wh

Re: Mozilla style guide issues, from a JS point of view

2014-01-09 Thread Mike Hoye
On 1/7/2014, 3:46 PM, Mike Hoye wrote: 2 v. 4 spaces: more on that shortly. An update on the research: Earlier, I said "four spaces" flat out, based on some conversations with researchers, but since then all the research I've been able to track down seems to cite the same paper. That paper

Re: Target Milestone field in bugzilla

2014-01-09 Thread Ryan VanderMeulen
On 1/9/2014 12:53 PM, Chris Peterson wrote: What is the use case for "Target Milestone" (in the "Patches Landed In" sense)? As you point out, the Target Milestone is not updated if a fix is uplifted, so Target Milestone does not even represent the first Gecko release that contains the fix. That i

Re: Style guide clarity on C++-isms

2014-01-09 Thread Ehsan Akhgari
On 1/9/2014, 11:48 AM, Milan Sreckovic wrote: if the goal of the styles is the readability, do we know that people actually care which one of the described approaches we use, or is it also the "look, not all of these things are the same" that offends us? For example, I find the consistency of

Re: Target Milestone field in bugzilla

2014-01-09 Thread Gavin Sharp
I'm sure there are other use cases, but the most common one for me is using it to sort out tracking flags for regressions and otherwise complicated dependency trees. Gavin On Thu, Jan 9, 2014 at 9:53 AM, Chris Peterson wrote: > On 1/9/14, 7:17 AM, Kartikaya Gupta wrote: >> >> I think the "Target

Re: Sharing string literals

2014-01-09 Thread Nicholas Nethercote
On Thu, Jan 9, 2014 at 3:33 AM, Neil wrote: > > Bug 514173 has landed, which makes use of the fact that code living in > libxul can reasonably assume that string constants have infinite lifetime, > meaning that any literal strings in libxul are shared rather than copied. Cool! Have you done any m

Re: Sharing string literals

2014-01-09 Thread Daniel Holbert
On 01/09/2014 03:33 AM, Neil wrote: > This does not apply to AssignLiteral on an nsString, since that used to > take a char (&)[] parameter. Instead, consider assigning an > NS_LITERAL_STRING, or you can also use the new char16_t overload of > AssignLiteral by wrapping your string constant in MOZ_U