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

On Wed, Apr 27, 2016 at 8:02 PM, Ehsan Akhgari wrote: > Hmm, OK, this is a good example. :-) > > Even though Xidorn's suggestion may work in some cases, I can imagine > that in other cases you wouldn't want the caller to have to know the > preconditions of calling

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

On Thursday, April 28, 2016 at 1:03:07 PM UTC+10, Ehsan Akhgari wrote: > [...] > What about having a MaybeMove function that implementation wise is the > same as Move, but is exempt from the static check? That name has the > advantage of making it clear that a move _may_ happen, but not

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

I filed a bug for that several months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1186706 Not sure why it gets stuck there. But it seems to me there was an issue that in many places in IPDL generated code, there is pattern like "DoSomething(mozilla::Move(foo), mozilla::Move(foo))", which

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

On Thu, Apr 28, 2016 at 11:02 AM, Ehsan Akhgari wrote: > On 2016-04-28 9:52 AM, Gerald Squelart wrote: > > 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

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

On 2016-04-28 9:52 AM, Gerald Squelart wrote: > 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:

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

On 2016-04-28 10:48 AM, Jed Davis wrote: > Kyle Huey writes: > >> Can we catch this pattern with a compiler somehow? >> >> Foo foo; >> foo.x = thing; >> DoBar(mozilla::Move(foo)); >> if (foo.x) { /* do stuff */ } > > https://bugzilla.mozilla.org/show_bug.cgi?id=1186706 >

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

Kyle Huey writes: > Can we catch this pattern with a compiler somehow? > > Foo foo; > foo.x = thing; > DoBar(mozilla::Move(foo)); > if (foo.x) { /* do stuff */ } https://bugzilla.mozilla.org/show_bug.cgi?id=1186706 ("Consider static analysis for Move semantics") There are

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

On Thu, Apr 28, 2016 at 9:52 AM, Gerald Squelart wrote: > 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

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, April 28, 2016 at 9:35:56 AM

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

On 2016-04-28 9:09 AM, Gerald Squelart wrote: > 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

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

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, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote: Can we catch this pattern with a compiler somehow?

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: > > >> Can we catch this

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 foo; > >> foo.x = thing; > >>

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

We could create a MoveGuard, similar to ReentrancyGuard, that sets a `moved = true` flag in debug builds and make methods assert against that. (But it isn't nearly as nice as having borrowck...) On Wed, Apr 27, 2016 at 5:53 PM, smaug wrote: > On 04/28/2016 08:00 AM, Gerald

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

On 2016-04-28 8:54 AM, Jack Moffitt wrote: > I apologize if this seemed flippant. I sent it sincerely to show that > such an analysis is possible, and it makes up one of the key features > of Rust. I have no idea how feasible this is to implement in C++, but > I suspect it must be hard as it is

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

On 2016-04-28 8:53 AM, smaug wrote: > On 04/28/2016 08:00 AM, Gerald Squelart wrote: > >> Because sometimes the function will choose not to actually move from >> an rvalue-ref > > FWIW, this is the reason why I think Move is broken by definition. Move > doesn't move anything. > It should have

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

On 04/28/2016 08:00 AM, Gerald Squelart wrote: Because sometimes the function will choose not to actually move from an rvalue-ref FWIW, this is the reason why I think Move is broken by definition. Move doesn't move anything. It should have been designed differently, so that a temporary

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

I apologize if this seemed flippant. I sent it sincerely to show that such an analysis is possible, and it makes up one of the key features of Rust. I have no idea how feasible this is to implement in C++, but I suspect it must be hard as it is one of the main motivations for Rust. jack. On Wed,

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

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 foo; >> foo.x = thing; >> DoBar(mozilla::Move(foo)); >> if (foo.x) { /* do stuff */ } I think so. We already have an

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

On Wed, Apr 27, 2016 at 5:29 PM, Kyle Huey wrote: > Can we catch this pattern with a compiler somehow? Yes. Example: foo.rs: struct Foo { x: u64, } fn do_bar(foo: Foo) { } fn main() { let foo = Foo { x: 0, }; do_bar(foo); if foo.x == 0 {

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

Static analysis for "use-after-move"?

Can we catch this pattern with a compiler somehow? Foo foo; foo.x = thing; DoBar(mozilla::Move(foo)); if (foo.x) { /* do stuff */ } - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: IIRFilterNode

Daniel Minor writes: > Summary: This provides an alternative to using BiquadFilterNode when > odd-order filters are required or automation is not needed. It is part of > the Web Audio spec and is already implemented in Blink. Thanks for looking at this, Daniel. I fear that high order filters

Re: How is libc shared object chosen in libxul?

On Thu, Apr 28, 2016 at 07:58:24AM +1200, Karl Tomlinson wrote: > libxul.so is dlopen()ed from the firefox process. That firefox > process would already have a libc.so.6, I assume, and so I would not > expect libxul.so to load another libc.so.6. It probably does here:

Re: How is libc shared object chosen in libxul?

libxul.so is dlopen()ed from the firefox process. That firefox process would already have a libc.so.6, I assume, and so I would not expect libxul.so to load another libc.so.6. That seems to be confirmed here by running strace -e trace=file firefox/firefox See whether something different is

Intent to implement and ship: IIRFilterNode

Summary: This provides an alternative to using BiquadFilterNode when odd-order filters are required or automation is not needed. It is part of the Web Audio spec and is already implemented in Blink. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1265408 Link to standard:

Re: Intent to remove:

Agreed. - jst On Tue, Apr 26, 2016 at 7:42 AM, Boris Zbarsky wrote: > I think removing this is reasonable at this point > > -Boris > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org >

Autoclassification of intermittent failures live on treeherder

Autoclassification of (a subset of) intermittent failures is now running on treeherder. You may have spotted that some jobs are now annotated with a hollow star symbol; this means that the autoclassifier matched all the error lines in that job with previously observed intermittents. The star

Re: Intent to remove:

On Tue, Apr 26, 2016 at 11:57 PM, Tantek Çelik wrote: > Henri, is there a particular release you plan to "unship" this for? -t I was thinking of 49, but if we decide we need telemetry, then my patch will rot and we'll wait for at least until 53. On Wed, Apr 27, 2016 at

Re: Intent to remove:

Strong agreement for removing . Looking at , it seems that Blink was successful in discouraging its use. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to remove:

On 2016-04-26 10:42 PM, Boris Zbarsky wrote: > I think removing this is reasonable at this point So... The last time that I personally used the "we're the only engine shipping this feature, therefore it must be safe to remove" argument for unshipping something, we ended up breaking a huge