Improve insert/emplace robustness to self insertion

[Jonathan Wakely]

On 30/06/16 21:51 +0200, François Dumont wrote:
>On 29/06/2016 23:30, Jonathan Wakely wrote:
>>
>>     iterator
>>     insert(const_iterator __position, value_type&& __x)
>>     { return emplace(__position, std::move(__x)); }
>>
>>That's suboptimal, since in the general case we need an extra
>>construction for emplacing, but we know that we don't need to do that
>>when inserting rvalues.
>
>    Why not ? I realized with your remarks that I was missing some 
>tests in the new self_insert.cc. The ones to insert an rvalue coming 
>from the vector itself. In the attached patch there is those 2 tests, 
>do you agree with expected behavior ? For the moment it doesn't check 
>that the source value has been indeed moved cause it doesn't, I will 
>update it once it does.

No, I don't agree, because this is undefined behaviour:

   vv.insert(vv.begin(), std::move(vv[0]));

We don't need to support that case.

17.6.4.9 [res.on.arguments] says:

— If a function argument binds to an rvalue reference parameter, the
  implementation may assume that this parameter is a unique reference
  to this argument.

i.e. when passed an rvalue we can assume it is not a reference to
something in the container.

That's why we should not perform any more operations when inserting
rvalues than we do now. Any increase in copies/moves for inserting
rvalues is a regression, and should be avoided.