Re: Code Review bot new reporting style

On Friday, March 27, 2020 at 11:11:46 PM UTC+11, Bastien Abadie wrote: > The code review bot has been updated today and now publishes all issues > found on your patches as Phabricator lint results (Diff Detail section) > instead of inline comments. > > Here is a sample revision showcasing the new

Re: How best to do async functions and XPCOM?

On Friday, December 6, 2019 at 9:20:21 AM UTC+11, Geoff Lankow wrote: > Hi all > > I'm redesigning a bunch of Thunderbird things to be asynchronous. I'd > like to use Promises but a lot of the time I'll be far from a JS context > so that doesn't really seem like an option. The best alternative

Re: Firefox Profiler now supports recording IPC messages

Unfortunately using the pref doesn't always work. Instead, go to the Firefox hamburger menu -> Web Developer -> Enable Profiler Toolbar Icon. It shows up as a small stopwatch. As Greg said, we're still in transition, sorry for the confusion! ;-) - Gerald On Thursday, October 31, 2019 at

Re: To what extent is sccache's distributed compilation usable?

On Tuesday, October 29, 2019 at 3:27:52 AM UTC+11, smaug wrote: > On 10/24/19 9:17 AM, Marcos Caceres wrote: > > On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester > > wrote: > >> As announced in this week's project call, sccache-dist schedulers have been > >> deployed to

Passing UniquePtr by value is more expensive than by rref

I'm in the middle of watching Chandler Carruth's CppCon talk "There Are No Zero-Cost Abstractions" and there's this interesting insight: https://youtu.be/rHIkrotSwcc?t=1041 The spoiler is already in the title (sorry!), which is that passing std::unique_ptr by value is more expensive than

Re: Structured bindings and minimum GCC & clang versions

On Friday, August 16, 2019 at 4:19:20 PM UTC+10, Henri Sivonen wrote: > This week, I wrote some code that made me wish we already had support > for structured bindings and return by initializer list (both from > C++17) for mozilla::Tuple. > > That is, if we have > mozilla::Tuple Foo() > it would

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

On Wednesday, July 10, 2019 at 9:12:23 AM UTC+10, Bobby Holley wrote: > On Tue, Jul 9, 2019 at 3:23 PM Mike Hommey wrote: > > > On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote: > > > On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart > > > wrote: > &

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

, Gerald On Thursday, July 4, 2019 at 3:11:27 PM UTC+10, Gerald Squelart wrote: > Recently I coded something with a not-very-important slow-changing > rarely-used positive number: `unsigned mGeneration;` > My reviewer commented: "Please use a type with an explicit size, such

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

(Glad I started this discussion; thank you Nathan for the enlightening links, I need to review all my code now!) Jeff, maybe what we need is a new value type that advertizes that it's unsigned, but doesn't have the unwanted 2^N wrapping (and its effects on bug-finding tools and compiler

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

On Thursday, July 4, 2019 at 4:53:34 PM UTC+10, Boris Zbarsky wrote: > On 7/4/19 10:11 PM, Gerald Squelart wrote: > > - I found plenty of `unsigned`s around, more than `uint32_t`s. > > How many are in code that predates the ability to use uint32_t, though? I didn't do deeper archa

Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

Recently I coded something with a not-very-important slow-changing rarely-used positive number: `unsigned mGeneration;` My reviewer commented: "Please use a type with an explicit size, such as uint32_t. (General mozilla style; you don't see a bare "unsigned" around much)" I had never heard of

Re: Rust required to build Gecko

On Tuesday, November 29, 2016 at 5:03:17 AM UTC+11, Gregory Szorc wrote: > > On Nov 27, 2016, at 14:46, Gerald Squelart <sque...@gmail.com> wrote: > > > >> On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote: > >> On Fri, Nov 25, 2016 at 7:48

Re: Rust required to build Gecko

On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote: > On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halberstadt > wrote: > > > For anyone confused by this, the binaries are downloaded to ~/.cargo/bin > > and adding this directory to your $PATH should fix the

Re: Linux content sandbox tightened

On Friday, October 7, 2016 at 6:49:53 PM UTC+11, Gian-Carlo Pascutto wrote: > Hi all, > > the next Nightly build will have a significantly tightened Linux > sandbox. Writes are no longer allowed except to shared memory (for IPC), > and to the system TMPDIR (and we're eventually going to get rid

Re: NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION

On Thursday, September 22, 2016 at 5:58:58 PM UTC+10, Paul Adenot wrote: > On Thu, Sep 22, 2016, at 07:33 AM, Gerald Squelart wrote: > > Sitting on the shoulders of giants, an idea, in the unlikely case it's > > not been thought of yet: > > How about an assertion that

Re: NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION

On Thursday, September 22, 2016 at 2:58:46 PM UTC+10, Daniel Holbert wrote: > On 09/21/2016 08:41 PM, Samael Wang wrote: > > The NS_ASSERTION document [1] says "Don't use NS_ASSERTION", which could be > > a bit confusing that now some of the similar named macros may be deprecated > > but some

Re: New [must_use] property in XPIDL

On the build-time vs static analysis point: I'd much prefer to have errors pointed out right from './mach build', which I can fix on the spot; rather than wait hours until I notice static analysis errors on a treeherder build. (e.g., I always forget explicit/MOZ_IMPLICIT!) Unless we can get

Re: Welcome new Data Stewardship Peers

On Thursday, July 14, 2016 at 6:51:21 AM UTC+10, Benjamin Smedberg wrote: > I'd like to welcome Chenxia Liu, François Marier, and Rebecca Weiss as > peers of Firefox Data Stewardship, joining Ally and myself. I'm excited to > bring a selection of people from across the organization who are

Re: MXR permanently offline, please transition to DXR

On Saturday, July 9, 2016 at 12:57:31 PM UTC+10, Boris Zbarsky wrote: > On 7/8/16 7:25 PM, Gerald Squelart wrote: > > The annotate (aka blame) functionality of hg.mozilla.org can point at one > > line > > Yes, I know. What it can't do is highlight some set of lines contai

Re: MXR permanently offline, please transition to DXR

On Saturday, July 9, 2016 at 7:21:24 AM UTC+10, Boris Zbarsky wrote: > On 7/8/16 4:18 PM, Steve Fink wrote: > > Are either mxr or dxr really the right thing for canonical links to our > > source code? As long as we're updating links, through one means or > > another, temporarily or permanently,

Re: Static analysis for "use-after-move"?

On Monday, May 2, 2016 at 9:49:24 AM UTC+10, Jim Blandy wrote: > No, we don't know that [moved-from strings become empty]. > The contract of a move in C++ is simply that the > source object is safe to destruct, but otherwise in an undefined state*. You > must not make any assumptions about its

Re: Return-value-optimization when return type is RefPtr

On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote: > On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote: > > On 06/16/2016 06:40 PM, smaug wrote: > > > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote: > > >> For > > >> >

Re: Return-value-optimization when return type is RefPtr

On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote: > On 06/16/2016 06:40 PM, smaug wrote: > > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote: > >> For > >> > >> RefPtr GetFoo() { > >>RefPtr foo; > >>// ... > >> } > >> > >> should we: > >> > >> 1. return foo and expect RVO to kick

Re: Return-value-optimization when return type is RefPtr

Coincidentally: (?) https://bugzilla.mozilla.org/show_bug.cgi?id=1280296 "remove already_AddRefed" :-) For your original question, I would vote for RVO when possible, and Move() otherwise. It feels like static analysis should be able to detect cases where RVO is possible and suggest it if

Re: Static analysis for "use-after-move"?

On Monday, May 2, 2016 at 9:49:24 AM UTC+10, Jim Blandy wrote: > On Fri, Apr 29, 2016 at 4:43 PM, Gerald Squelart <squel...@gmail.com> wrote: > > > For example, we know how strings behave when moved from* (the original > > becomes empty), and it'd be nice to be abl

Re: Static analysis for "use-after-move"?

On Saturday, April 30, 2016 at 9:43:46 AM UTC+10, Gerald Squelart wrote: > On Friday, April 29, 2016 at 2:15:03 PM UTC+10, Jim Blandy wrote: > > On Thu, Apr 28, 2016 at 8:22 PM, <jw...@mozilla.com> wrote: > > > > > Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道： >

Re: Static analysis for "use-after-move"?

On Friday, April 29, 2016 at 2:15:03 PM UTC+10, Jim Blandy wrote: > On Thu, Apr 28, 2016 at 8:22 PM, wrote: > > > Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道： > > > I don't really think it's a good example. TakeMediaIfKnown is accepting a > > > UniquePtr as an inout parameter:

Re: MOZ_WARN_UNUSED_RESULT has been renamed as MOZ_MUST_USE

On Friday, April 29, 2016 at 8:04:46 PM UTC+10, Nicholas Nethercote wrote: > On Fri, Apr 29, 2016 at 10:25 AM, Nicholas Nethercote > wrote: > > > > I just landed on inbound the patches in bug 1267550, which renamed > > MOZ_WARN_UNUSED_RESULT as MOZ_MUST_USE. > > > > A shorter

Re: Static analysis for "use-after-move"?

_may_ happen, but not necessarily. > On 2016-04-28 9:52 AM, Gerald Squelart wrote: > > Anyway, how about this: > > - mozilla::Move() is reserved for expected moves, and *any* re-use after > > that is considered an error. > > - We introduce something like mozilla::MakeAvailable

Re: Static analysis for "use-after-move"?

On Thursday, April 28, 2016 at 11:25:38 AM UTC+10, Ehsan Akhgari wrote: > On 2016-04-28 9:00 AM, Gerald Squelart wrote: > > On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote: > >> On 2016-04-28 8:00 AM, Gerald Squelart wrote: > >>> On Thursday, Ap

Re: Static analysis for "use-after-move"?

On Thursday, April 28, 2016 at 11:00:12 AM UTC+10, Gerald Squelart wrote: > On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote: > > On 2016-04-28 8:00 AM, Gerald Squelart wrote: > > > On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote: &

Re: Static analysis for "use-after-move"?

On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote: > On 2016-04-28 8:00 AM, Gerald Squelart wrote: > > On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote: > >> Can we catch this pattern with a compiler somehow? > >> > >> Foo

Re: Static analysis for "use-after-move"?

On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote: > Can we catch this pattern with a compiler somehow? > > Foo foo; > foo.x = thing; > DoBar(mozilla::Move(foo)); > if (foo.x) { /* do stuff */ } > > - Kyle Definitely something that would be nice. But if we have/implement such a

Re: Automation / Firefox 48 switched to Visual Studio 2015 Update 2

On Saturday, April 23, 2016 at 6:25:36 AM UTC+10, Gregory Szorc wrote: > Visual Studio 2015 Update 2 was released just days after we switched > automation from VS2013 to VS2015 Update 1. We know we were going to take > Update 2 eventually and we didn't want to run a Windows toolchain for as >

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thursday, April 21, 2016 at 4:33:40 PM UTC+10, Nicholas Nethercote wrote: > On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote: > >> > >> Maybe you're referring to factory methods, like this: > >> > >> static T* T::New(); > >> > >> which would return null on failure. Such

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thursday, April 21, 2016 at 11:15:10 AM UTC+10, Nicholas Nethercote wrote: > Hi, > > C++ constructors can't be made fallible without using exceptions. As a result, > for many classes we have a constructor and a fallible Init() method which must > be called immediately after construction. > >

Re: The convention to pass a parameter when ownership transfer is optional

On Friday, March 18, 2016 at 2:07:34 PM UTC+11, jww...@mozilla.com wrote: > https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/mfbt/UniquePtr.h#l182 > > "To unconditionally transfer ownership of a UniquePtr into a method, use a > |UniquePtr| argument. To

Re: Decommissioning "dumbmake"

On Monday, October 19, 2015 at 11:09:46 AM UTC+11, Eric Rescorla wrote: > On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote > wrote: > > > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote: > > > > > > What's needed here is a dependency management system that > > > simply builds what's

Re: easily getting allocation stacks for leaking objects

Good stuff! I hope you'll consider tracking AddRef's and Release's as well. I recently experimented with that for a troubled RefCounted class [1], and it was very useful to find which AddRef didn't have its corresponding Release. Cheers, Gerald [1] https://hg.mozilla.org/try/rev/8dffaf0d2acf

Re: easily getting allocation stacks for leaking objects

On Friday, September 18, 2015 at 3:55:27 AM UTC+10, Andrew McCreight wrote: > On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight > wrote: > > > > On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart > > wrote: > > > >> Good stuff! > >> > >> I hop

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

Will there be a blanket change sometime soon? If not, are we supposed to start using the new style in patches now, even when it would clash with nearby old-style overrides/finals in the same file or in the same directory? ___ dev-platform mailing list