Re: C++ method definition comments

2019-01-29 Thread gsquelart
On Wednesday, January 30, 2019 at 9:57:02 AM UTC+11, Ehsan Akhgari wrote: > On Mon, Jan 28, 2019 at 7:10 PM wrote: > > > Just a thought: Would it be worth considering a blank macro, e.g.: > > static void foo(); > > DECLARED_STATIC void foo() {...} > > > > On top of not being confused with other

Re: C++ method definition comments

2019-01-28 Thread gsquelart
Just a thought: Would it be worth considering a blank macro, e.g.: static void foo(); DECLARED_STATIC void foo() {...} On top of not being confused with other comments around, it could be clang-checked so it's never wrong. (And maybe eventually enforced, like MOZ_IMPLICIT is.) Cheers, Gerald

Re: Upcoming C++ standards meeting in San Diego, California

2018-10-22 Thread gsquelart
On Tuesday, October 23, 2018 at 10:57:59 AM UTC+11, Botond Ballo wrote: > On Mon, Oct 22, 2018 at 7:47 PM, wrote: > > Here's one I'd like: > > for (int i = ...; test(i); i = next(i)) { > > if (good_stuff(i)) { break; /* goto past `else` block */ } > > } else { > > /* test(i) failed,

Re: Upcoming C++ standards meeting in San Diego, California

2018-10-22 Thread gsquelart
On Tuesday, October 23, 2018 at 8:52:47 AM UTC+11, Botond Ballo wrote: > I will be attending this meeting So jealous! Enjoy ;-) > Finally, I encourage you to reach out to me if you're thinking of > submitting a proposal to the committee. I'm always happy to help with > formulating and, if

Re: Plan for Sunsetting MozReview

2018-08-27 Thread gsquelart
(Disclaimer: I'm not from IT!) Until this gets fixed, a workaround for closed bugs is to go to the bottom of the bug, and look for https://hg.mozilla.org/mozilla-central/rev/... links. Not as pretty, and missing review context, but hopefully this should help explore the changed code in most

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

2018-07-13 Thread gsquelart
On Wednesday, July 11, 2018 at 4:19:15 AM UTC+10, Kris Maglione wrote: > [...] > Essentially what this means, though, is that if we identify an area of > overhead that's 50KB[3] or larger that can be eliminated, it *has* to be > eliminated. There just aren't that many large chunks to remove.

Re: Coding style: brace initialization syntax

2018-06-05 Thread gsquelart
On Wednesday, June 6, 2018 at 5:35:59 AM UTC+10, Boris Zbarsky wrote: > On 6/5/18 3:10 PM, Emilio Cobos Álvarez wrote: > > I personally would prefer one space at each side when using braces: > > > >  , mFoo { 0 } > > I think the reason people tend to think of this as not wanting spaces is >

Re: PSA: Building Firefox 61+ with GCC will soon require version GCC 6.1+

2018-04-09 Thread gsquelart
Good stuff, thanks Jeff! To be pedantic, don't you mean "start relying on *more* c++14 features"? Because we've already been able to use some C++14 features since November 2017 (see bug 1325632, landed in 59). E.g., I and others have used initialized lambda captures since then -- saving quite

Hiding 'new' statements - Good or Evil?

2017-11-22 Thread gsquelart
Should we allow hiding 'new' statements, or keep them as visible as possible? Some context: Recently in bug 1410252 I added a MakeNotNull(args...) function that does `NotNull(new T(args...))`, in the style of MakeUnique and others. It also works with RefPtr. My first goal was to avoid

Re: mozilla-central now compiles with C++14

2017-11-16 Thread gsquelart
On Friday, November 17, 2017 at 6:05:38 AM UTC+11, Jeff Walden wrote: > On 11/16/2017 08:35 AM, Ben Kelly wrote: > > I would like to use initialized lambda capture as I think it will allow > > move-only objects to be used in lambdas like this: > > > > UniquePtr uniqueThing = MakeUnique(); > >

Re: Are char* and uint8_t* interchangeable?

2017-11-08 Thread gsquelart
On Thursday, November 9, 2017 at 1:11:20 PM UTC+11, Kris Maglione wrote: > On Wed, Nov 08, 2017 at 06:04:27PM -0800, jww...@mozilla.com wrote: > >Is it always safe and portable to do: > > > >char* p1 = ...; > >uint8_t* p2 = reinterpret_cast(p1); > >uint8_t u8 = p2[0]; > > > >without

Re: Coding style: `else for` or `else { for... }`?

2017-08-30 Thread gsquelart
Only negative reactions to `else for` so far, and it's only used a couple of times in our code: http://searchfox.org/mozilla-central/search?q=else%5B+%5D%2B(do%7Cfor%7Cswitch%7Cwhile)%5B+%5D=true=true=*.cpp So I'll add a clarification in the coding style page, that `else` should only be

Coding style: `else for` or `else { for... }`?

2017-08-30 Thread gsquelart
Let's keep the flames alive! Should we always put braces after an `else`, with the only exception being another `if`? Or should we also have exceptions for the other control structures (while, do, for, switch)? A. if (...) { ... } else { for (...) { ... } } B. if (...) { ... }

Re: Extensions and Gecko specific APIs

2017-07-25 Thread gsquelart
On Wednesday, July 26, 2017 at 8:21:23 AM UTC+12, Andrew Overholt wrote: > On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: > > > Should we moz-prefix moz-specific extensions? > > > We have been trying not to do that for Web-exposed APIs but maybe the > extensions case

Re: Improving visibility of compiler warnings

2017-05-25 Thread gsquelart
On Friday, May 26, 2017 at 11:08:09 AM UTC+12, Andrew McCreight wrote: > On Thu, May 25, 2017 at 4:03 PM, wrote: > > > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote: > > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: > > > > On 05/19/2017 02:44 PM,

Re: Improving visibility of compiler warnings

2017-05-25 Thread gsquelart
On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote: > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: > > On 05/19/2017 02:44 PM, Gregory Szorc wrote: > >> `mach build` attempts to parse compiler warnings to a persisted > >> "database." > >> You can view a list of compiler warnings

Re: A reminder about commit messages: they should be useful

2017-04-17 Thread gsquelart
On Tuesday, April 18, 2017 at 11:58:11 AM UTC+12, smaug wrote: > On 04/18/2017 02:36 AM, Gregory Szorc wrote: > > On Mon, Apr 17, 2017 at 4:10 PM, smaug wrote: > > > >> On 04/17/2017 06:16 PM, Boris Zbarsky wrote: > >> > >>> A quick reminder to patch authors and reviewers. > >>>

Re: mozIntl.DateTimeFormat

2017-04-09 Thread gsquelart
On Friday, April 7, 2017 at 11:22:17 AM UTC+12, zbran...@mozilla.com wrote: > Hi all, > > We completed the transition of the Intl handling from using OS locale, to use > browser UI locale. > > We have a new API called mozIntl.DateTimeFormat which should be the primary > way we format date and

Re: Please do NOT hand-edit web platform test MANIFEST.json files

2017-03-22 Thread gsquelart
On Saturday, March 18, 2017 at 5:01:17 AM UTC+11, Boris Zbarsky wrote: > We have tools for this: "mach wpt-manifest-update" will do the right thing. > > The typical result of hand-edits is that later changesets that do use > the tools end up conflicting with each other, as they all fix up the >

Re: Please do NOT hand-edit web platform test MANIFEST.json files

2017-03-20 Thread gsquelart
On Tuesday, March 21, 2017 at 2:58:17 AM UTC+11, Boris Zbarsky wrote: > On 3/19/17 12:36 AM, Nils Ohlmeier wrote: > > Wouldn’t it make more sense to let the build system detect and reject/warn > > about (?) such a manual modification? > > That would be ideal, but there are some issues with doing

Re: The future of commit access policy for core Firefox

2017-03-11 Thread gsquelart
On Sunday, March 12, 2017 at 1:23:45 AM UTC+11, smaug wrote: > On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: > > On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < > > gov...@lists.mozilla.org> wrote: > >> > >> I'd be ok to do a quick r+ if interdiff was working well. > > > > Depending

Re: All the processes

2017-03-06 Thread gsquelart
Just about the "4 good, 8 bad" part, it seems quite arbitrary -- Wouldn't that be hardware-dependent? I would think users with "only" 1GB may have different needs and expectations from users with 16+GB. Intuitively I don't grasp how each content process can add that much more memory that it

Re: Doxygen output?

2017-02-20 Thread gsquelart
My short (<2yr) experience of the code gave me the impression that only a small amount of it has proper doxygen comments. We must be frequenting different circles; or I'm somehow blind to them. :-) Anyway, they're mainly useful when generated websites/documents are readily available, which it

Re: Should &&/|| really be at the end of lines?

2017-02-17 Thread gsquelart
On Saturday, February 18, 2017 at 10:50:24 AM UTC+11, Boris Zbarsky wrote: > On 2/17/17 5:44 PM, gsqu...@mozilla.com wrote: > > - People who stick with the official parser will only ever see that > > (pushing to mozreview will reformat everything to the official style). > > Not all reviews go

Re: Should &&/|| really be at the end of lines?

2017-02-17 Thread gsquelart
On Saturday, February 18, 2017 at 9:29:06 AM UTC+11, Bobby Holley wrote: > On Fri, Feb 17, 2017 at 2:18 PM, wrote: > > > Hi again Nick, > > > > Someone made me realize that I didn't fully read your message, sorry for > > that. > > > > I now see that as well as &&/||, you

Re: Should &&/|| really be at the end of lines?

2017-02-17 Thread gsquelart
Hi again Nick, Someone made me realize that I didn't fully read your message, sorry for that. I now see that as well as &&/||, you have grepped for other operators, and shown that the overwhelming usage is to put all of them at the end of lines! In light of this, and from what others here have

Re: Should &&/|| really be at the end of lines?

2017-02-16 Thread gsquelart
Of course grepping agrees with you, since it's been the coding style so far! ;-) I was hoping to change that, if most people agreed. While it's good to know how many people are for or against it, so that we get a sense of where the majority swings, I'd really like to know *why* people have

Re: Should &&/|| really be at the end of lines?

2017-02-16 Thread gsquelart
Thank you David. Your opinion about any *future* change to &&/|| style would be appreciated. ;-) About "increased disruption to blame that makes understanding the history of our code harder": I think some tools like http://searchfox.org/ have considerably lessened the impact to blame, because

Re: Should &&/|| really be at the end of lines?

2017-02-16 Thread gsquelart
Jeff, I see you're opinionated against consistency. :-) Or you think there are other more important things? Anyway, I'm not exactly sure what you're advocating. Could you please elaborate? On Friday, February 17, 2017 at 10:11:25 AM UTC+11, Jeff Gilbert wrote: > I would not assume that's

Re: Should &&/|| really be at the end of lines?

2017-02-16 Thread gsquelart
There's an ongoing effort to use clang-format to automatically format All The Codes [1], so I think we should try and make sure we agree (or at least settle*) on a coding style when it's going to be enforced everywhere. ;-) * I'm presenting my own preferences here, but in the end I'm fine with

Should &&/|| really be at the end of lines?

2017-02-16 Thread gsquelart
Question of the day: When breaking overlong expressions, should &&/|| go at the end or the beginning of the line? TL;DR: Coding style says 'end', I think we should change it to 'beginning' for better clarity, and consistency with other operators. Our coding style reads: "Break long conditions

Re: A reminder about MOZ_MUST_USE and [must_use]

2017-01-19 Thread gsquelart
On Friday, January 20, 2017 at 10:36:46 AM UTC+11, Bobby Holley wrote: > On Thu, Jan 19, 2017 at 3:26 PM, wrote: > > > On Friday, January 20, 2017 at 10:13:54 AM UTC+11, Nicholas Nethercote > > wrote: > > > On Fri, Jan 20, 2017 at 10:01 AM, wrote: > > >

Re: A reminder about MOZ_MUST_USE and [must_use]

2017-01-19 Thread gsquelart
On Friday, January 20, 2017 at 10:13:54 AM UTC+11, Nicholas Nethercote wrote: > On Fri, Jan 20, 2017 at 10:01 AM, wrote: > > > And the next step would be to make must-use the default, and have > > MOZ_CAN_IGNORE for the rest. ;-) > > > > I actually tried this with all XPIDL

Re: A reminder about MOZ_MUST_USE and [must_use]

2017-01-19 Thread gsquelart
And the next step would be to make must-use the default, and have MOZ_CAN_IGNORE for the rest. ;-) Gerald (who is not volunteering!) On Friday, January 20, 2017 at 9:30:13 AM UTC+11, Eric Rescorla wrote: > What would actually be very helpful would be a way to selectively turn on > checking of >

forward declarations vs includes

2017-01-11 Thread gsquelart
Controversy! Our beloved coding style reads: "Forward-declare classes in your header files instead of including them whenever possible." https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#CC_practices I guess the main goal is to keep build times lower by reducing the

Re: GCC 4.9 now required to build on Linux/Android

2016-12-23 Thread gsquelart
On Saturday, December 24, 2016 at 3:08:21 AM UTC+11, Nathan Froyd wrote: > Bug 1322792 has landed on inbound, which changes configure to require > GCC 4.9 to build; our automation switched over to GCC 4.9 for our > Linux builds earlier this week. (Android builds have been using GCC > 4.9 for some

Re: rvalue references: Implicit move method generation cannot be used?

2015-05-17 Thread gsquelart
Just found this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3153.htm Showing that implicit move can have adverse effects, especially when blindly applied to pre-C++11 code. Could it be why MS doesn't want to implement it? '=default' should theoretically be fine, since the

rvalue references: Implicit move method generation cannot be used?

2015-05-17 Thread gsquelart
In Using C++ in Mozilla code ( https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code ) there is this note: rvalue references: Implicit move method generation cannot be used First written before Aug 2013, updated by Jcranmer on January 26, 2015 Could we get more details please,