On 7/12/21 5:02 AM, Richard Biener wrote:
> On Wed, Jul 7, 2021 at 4:37 PM Martin Sebor <msebor@gmail.com> wrote:
>>
>> On 7/7/21 1:28 AM, Richard Biener wrote:
>>> On Tue, Jul 6, 2021 at 5:06 PM Martin Sebor <msebor@gmail.com> wrote:
>>>>
>>>> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573968.html
>>>>
>>>> Any questions/suggestions on the final patch or is it okay to commit?
>>>
>>> I don't remember seeing one (aka saying "bootstrapped/tested, OK to commit?"
>>> or so) - and the link above doesn't have one.
>>>
>>> So, can you re-post it please?
>>
>> The patch is attached to the email above with the following text
>> at the end:
>>
>>     Attached is a revised patch with these changes (a superset of
>>     those I sent in response to Jason's question), tested on x86_64.
>>
>> I've also attached it to this reply.
> 
> Thanks - I was confused about the pipermail way of referencing attachments ...
> 
> The pieces where you change vec<> passing to const vec<>& and the few
> where you change vec<> * to const vec<> * are OK - this should make the
> rest a smaller piece to review.  In general const correctness changes should
> be considered obvious (vec<> to const vec<>& passing isn't quite obvious
> so I acked the cases explicitely).

Okay.

> 
> I think the vec<> -> vec<>& cases would either benefit from constification
> of callers that make using const vec<>& not possible or from a change to
> pass array_slice<> (not array_slice<>&), noting that the vec<> contents
> are mutated but the vec<> size does not change.

I've reviewed the patch and found a handful of instances I had missed
where the vec& could be made const.   The rest of the vec<> -> vec<>&
changes are all to functions that modify the vec, either directly or
by passing it to other functions that do.  (I you see some you want
me to double-check let me know.)

As a reminder, there may still be APIs where an existing by-value or
by-reference vec could be made const vec& if they don't have to be
touched for other reasons (i.e., passing an auto_vec as an argument).
Those should also be reviewed at some point.

> 
> Somebody with more C++ knowledge than me needs to approve the
> vec.h changes - I don't feel competent to assess all effects of the change.

Ack.

Attached is an updated patch with a few of the vec& -> const vec&
changes and the removal of the static specifier on vNULL.

Martin