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
>
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 methods. After adding
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:
> > >
> > > > And the next step would be to make
On Tuesday, February 14, 2017 at 3:25:05 AM UTC+11, Ehsan Akhgari wrote:
> On 2017-02-11 3:27 AM, ISHIKAWA,chiaki wrote:
> > On 2017/02/11 7:07, Botond Ballo wrote:
> >> On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic
> >> wrote:
> >>> First step needs to happen completely before the second step
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&others think we should change it to
'beginning' for better clarity, and consistency with other operators.
Our coding style reads:
"Break long cond
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
Forgot the link:
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1188202
On Friday, February 17, 2017 at 10:04:49 AM UTC+11, gsqu...@mozilla.com wrote:
> 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
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 necessari
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 th
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
their
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&elsew
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 have grepped for other op
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 thr
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 se
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 wou
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 on
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
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
>
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 t
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.
> >>>
> >>> Changesets s
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 post
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, Gregory Szorc wrote:
> > > >
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 is different?
> https
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 (...) {
...
} else
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&case=true®exp=true&path=*.cpp
So I'll add a clarification in the coding style page, that `else` should onl
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 breaking strict
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();
> > nsCO
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 the unne
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 a
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
> tha
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. They
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
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 n
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,
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 developer
(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 case
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 necessa
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, i
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
O
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 c
40 matches
Mail list logo
