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

2016-07-07 Thread Jim Blandy
Yes, that's part of the standard expectations for std::move, and thus mozilla::Move as well. On Thu, Jul 7, 2016 at 6:53 AM, Gerald Squelart wrote: > 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].

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

2016-07-07 Thread Gerald Squelart
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: Static analysis for "use-after-move"?

2016-05-02 Thread Jason Orendorff
On Sun, May 1, 2016 at 7:39 PM, Gerald Squelart wrote: > Thinking of it, I suppose lots (all?) of these optimized content-stealing > actions could be done through differently-named methods (e.g. 'Take()'), so > they could not possibly be confused with C++ move semantics. >

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

2016-05-01 Thread Gerald Squelart
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 wrote: > > > For example, we know how strings behave when moved from* (the original > > becomes empty), and it'd be nice to be able to use that trick when

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

2016-05-01 Thread Jim Blandy
On Fri, Apr 29, 2016 at 4:43 PM, Gerald Squelart wrote: > For example, we know how strings behave when moved from* (the original > becomes empty), and it'd be nice to be able to use that trick when possible > and really needed. > No, we don't know that. The contract of a

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

2016-04-29 Thread Gerald Squelart
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, wrote: > > > > > Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道： > > > > I don't really think it's a

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

2016-04-29 Thread Gerald Squelart
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: Static analysis for "use-after-move"?

2016-04-29 Thread Michael Layzell
I have already written a basic analysis for use-after-move semantics which just hasn't been reviewed yet. I'm not sure if it's what you'd be looking for (take a look at the tests). https://bugzilla.mozilla.org/show_bug.cgi?id=1186706 Michael On Fri, Apr 29, 2016 at 12:14 AM, Jim Blandy

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

2016-04-28 Thread Jim Blandy
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: it uses, and may modify, its > > value. It should take UniquePtr &. >

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

2016-04-28 Thread jwwang
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: it uses, and may modify, its > value. It should take UniquePtr &. IIUC, UniquePtr can't be an inout parameter for its unique semantics which

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

2016-04-28 Thread Karl Tomlinson
Xidorn Quan writes: > I think this specific case should actually use UniquePtr& rather > than && in parameter for conditional move, so that callsite can only pass > in an lvalue, and we don't need a Move there. Jim Blandy writes: > TakeMediaIfKnown is accepting a > UniquePtr as an inout

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

2016-04-27 Thread Jim Blandy
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"?

2016-04-27 Thread Gerald Squelart
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"?

2016-04-27 Thread Xidorn Quan
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"?

2016-04-27 Thread Xidorn Quan
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"?

2016-04-27 Thread Ehsan Akhgari
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"?

2016-04-27 Thread Ehsan Akhgari
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"?

2016-04-27 Thread Jed Davis
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"?

2016-04-27 Thread Xidorn Quan
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"?

2016-04-27 Thread Gerald Squelart
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"?

2016-04-27 Thread Ehsan Akhgari
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"?

2016-04-27 Thread Ehsan Akhgari
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"?

2016-04-27 Thread Gerald Squelart
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"?

2016-04-27 Thread Gerald Squelart
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"?

2016-04-27 Thread Nick Fitzgerald
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"?

2016-04-27 Thread Ehsan Akhgari
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"?

2016-04-27 Thread Ehsan Akhgari
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"?

2016-04-27 Thread smaug
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"?

2016-04-27 Thread Jack Moffitt
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"?

2016-04-27 Thread Ehsan Akhgari
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"?

2016-04-27 Thread Jack Moffitt
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"?

2016-04-27 Thread Gerald Squelart
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"?

2016-04-27 Thread Kyle Huey
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