[llvm] r215478 - APInt: Make self-move-assignment a no-op to fix stage3 clang-cl

[David Blaikie]

On Thu, Aug 14, 2014 at 2:42 PM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Aug 12, 2014 at 3:29 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> On Tue, Aug 12, 2014 at 3:01 PM, Reid Kleckner <reid at kleckner.net> wrote:
>> > Author: rnk
>> > Date: Tue Aug 12 17:01:39 2014
>> > New Revision: 215478
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=215478&view=rev
>> > Log:
>> > APInt: Make self-move-assignment a no-op to fix stage3 clang-cl
>> >
>> > It's not clear what the semantics of a self-move should be.  The
>> > consensus appears to be that a self-move should leave the object in a
>> > moved-from state, which is what our existing move assignment operator
>> > does.
>> >
>> > However, the MSVC 2013 STL will perform self-moves in some cases.  In
>> > particular, when doing a std::stable_sort of an already sorted APSInt
>> > vector of an appropriate size, one of the merge steps will self-move
>> > half of the elements.
>> >
>> > We don't notice this when building with MSVC, because MSVC will not
>> > synthesize the move assignment operator for APSInt.  Presumably
>>
>> I'm assuming you're going to look into this a bit further, though?
>> (other than just 'presumably') both to understand when/how long we
>> need this workaround in place, and whether we need to do anything to
>> Clang for MSVC compatibility here?
>
>
> David Majnemer says that VS 2013 can't generate implicit move assignments at
> all, so I just gave up too early and rationalized it.

Oh, right, yes.

>
>>
>> > MSVC
>> > does this because APInt, the base class, has user-declared special
>> > members that implicitly delete move special members.  Instead, MSVC
>> > selects the copy-assign operator, which defends against self-assignment.
>> > Clang, on the other hand, selects the move-assign operator, and we get
>> > garbage APInts.
>>
>> I'm curious how Clang synthesizes a move assignment operator if the
>> base class's move assignment is implicitly deleted. Any idea what's
>> going on there?
>
>
> The base class (APInt) has a user-defined move assignment, which is the one
> that I'm modifying here. We reach it in Clang through an implicit APSInt
> move assignment, but MSVC doesn't generate that and doesn't reach it.

Yep, that all makes sense.

Reckon we need to disable generation of implicit move members in MSVC
compatibility mode?