Re: [PATCH] add move CTOR to auto_vec, use auto_vec for get_loop_exit_edges

[Jonathan Wakely <jwakely@redhat.com>]

On 24/09/20 11:11 +0200, Richard Biener wrote:
>On Wed, 26 Aug 2020, Richard Biener wrote:
>
>> On Thu, 6 Aug 2020, Richard Biener wrote:
>>
>> > On Thu, 6 Aug 2020, Richard Biener wrote:
>> >
>> > > This adds a move CTOR to auto_vec<T, 0> and makes use of a
>> > > auto_vec<edge> return value for get_loop_exit_edges denoting
>> > > that lifetime management of the vector is handed to the caller.
>> > >
>> > > The move CTOR prompted the hash_table change because it appearantly
>> > > makes the copy CTOR implicitely deleted (good) and hash-table
>> > > expansion of the odr_enum_map which is
>> > > hash_map <nofree_string_hash, odr_enum> where odr_enum has an
>> > > auto_vec<odr_enum_val, 0> member triggers this.  Not sure if
>> > > there's a latent bug there before this (I think we're not
>> > > invoking DTORs, but we're invoking copy-CTORs).
>> > >
>> > > Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>> > >
>> > > Does this all look sensible and is it a good change
>> > > (the get_loop_exit_edges one)?
>> >
>> > Regtest went OK, here's an update with a complete ChangeLog
>> > (how useful..) plus the move assign operator deleted, copy
>> > assign wouldn't work as auto-generated and at the moment
>> > there's no use of assigning.  I guess if we'd have functions
>> > that take an auto_vec<> argument meaning they will destroy
>> > the vector that will become useful and we can implement it.
>> >
>> > OK for trunk?
>>
>> Ping.
>
>Ping^2.

Looks good to me as far as the use of C++ features goes.