IPDL Changes: Refcounted Types

Earlier this week, bug 1443954 landed, which improved support in IPDL for reference counted types, making it safer and more ergonomic to directly use reference counted types (such as nsIURI, nsIPrincipal, nsIInputStream, etc.) in IPDL

Re: Are there some lists of web sites which use vertical writing-mode?

There's a 100% vertical writing mode demo here: https://www.chenhuijing.com/zh-type/ (Blog post about it here: https://www.chenhuijing.com/blog/chinese-web-typography/#lets-build-a-demo) On Monday, April 9, 2018 at 11:39:34 AM UTC-4, masayuki nakano wrote: > Hi, > > I'm currently reviewing

Re: Coding style: brace initialization syntax

On Fri, Apr 13, 2018 at 11:06 AM, Emilio Cobos Álvarez wrote: >> If we are going to have brace-initialization intermixed with >> list-initialization (i.e. parentheses) in our codebase, I think we >> should prefer no space prior to the brace, for consistency. > > Hmm, consistency

Re: Coding style: brace initialization syntax

On Fri, Apr 13, 2018 at 11:06 AM, Emilio Cobos Álvarez wrote: > I'd be ok with that I guess, though it's more common each time? Also, is > there any case where you could use braces but not parenthesis? (I'm not a > C++ expert in this regard). I think there are. In particular if

Re: Coding style: brace initialization syntax

On 4/13/18 4:49 PM, Nathan Froyd wrote: On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez wrote: Those changes I assume were generated with clang-format / clang-format-diff using the "Mozilla" coding style, so I'd rather ask people to agree in whether we prefer that style

Re: Coding style: brace initialization syntax

On 13/04/2018 16:49, Nathan Froyd wrote: > I lean towards the former here. I think the former is more common in > the code I've seen, but apparently the latter is "preferred C++" or > something? Yes, let's have a solid rationale if we're doing sweeping changes of this sort. Blindly following the

Re: Coding style: brace initialization syntax

On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez wrote: > Those changes I assume were generated with clang-format / clang-format-diff > using the "Mozilla" coding style, so I'd rather ask people to agree in > whether we prefer that style or other in order to change that if

Re: Coding style: brace initialization syntax

On 4/13/18 9:40 AM, Alex Gaynor wrote: I don't have an opinion on the style change itself, but I'm a very strong +1 on just picking one and making sure clang-format enforces it. We need to fix clang-format to not produce output like

Re: Coding style: brace initialization syntax

On 4/13/18 9:37 AM, Emilio Cobos Álvarez wrote: Would people agree to use:  , mIsRootDefined { false } Instead of:  , mIsRootDefined{ false } So my take is that we should not use braced initializer syntax in constructor initializer lists. The reason for that is that it makes it much

Re: Coding style: brace initialization syntax

I don't have an opinion on the style change itself, but I'm a very strong +1 on just picking one and making sure clang-format enforces it. Alex On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez wrote: > Sorry, I know, coding style thread... But it's Friday and this is

Coding style: brace initialization syntax

Sorry, I know, coding style thread... But it's Friday and this is somewhat related to the previous thread. Bug 525063 added a lot of lines like: explicit TTextAttr(bool aGetRootValue) : mGetRootValue(aGetRootValue) , mIsDefined{ false } , mIsRootDefined{ false } {

Re: redundant(?) code churn and code style issues in bug 525063

I come with a followup on this matter, we’ve backed out the issues. Now the tree should be OK. Please see: https://hg.mozilla.org/mozilla-central/rev/8a94faa5cc60495da5d80d4b3c07bf5877d2e6d8 Thanks, ANdi >

Re: redundant(?) code churn and code style issues in bug 525063

Hello all, Right now we are working on backing out the changes the caused this. I will keep you posted when this is done. P.S it should be done very shortly. > On 13 Apr 2018, at 15:48, Nathan Froyd wrote: > > we're signature.asc Description: Message signed with

Re: redundant(?) code churn and code style issues in bug 525063

FWIW, all these complaints (and more) have been raised in the bug. I'm not entirely sure what we're going to do yet, but rest assured that people are definitely aware of the issues. Thanks, -Nathan On Fri, Apr 13, 2018 at 8:31 AM, Kartikaya Gupta wrote: > On Fri, Apr 13,

Re: redundant(?) code churn and code style issues in bug 525063

On Fri, Apr 13, 2018 at 6:18 AM, Jonathan Kew wrote: > It's presumably auto-generated by a static-analysis tool or something like > that, but ISTM it has been overly aggressive, adding a lot more code churn > than necessary (as well as committing some pretty extreme style

redundant(?) code churn and code style issues in bug 525063

The huge patch that recently hit mozilla-central in bug 525063 makes me a bit sad. Did we really need to do this? On this scale? It's presumably auto-generated by a static-analysis tool or something like that, but ISTM it has been overly aggressive, adding a lot more code churn than necessary