On 11/20/18 8:28 AM, Martin Sebor wrote:
> On 11/20/2018 02:21 AM, Richard Biener wrote:
>> On Mon, Nov 19, 2018 at 4:36 PM Martin Sebor <mse...@gmail.com> wrote:
>>>
>>> On 11/19/2018 03:32 AM, Richard Biener wrote:
>>>> On Sat, Nov 17, 2018 at 12:05 AM Martin Sebor <mse...@gmail.com> wrote:
>>>>>
>>>>> To encourage and simplify the adoption of iterator classes in
>>>>> GCC the attached patch turns the function_args_iterator struct
>>>>> into an (almost) proper C++ iterator class that can be used
>>>>> the same way as traditional forward iterators.
>>>>>
>>>>> The patch also replaces all of the 26 uses of the legacy
>>>>> FOREACH_FUNCTION_ARGS macro with ordinary for loops that use
>>>>> function_args_iterator directly, and also poisons both
>>>>> FOREACH_FUNCTION_ARGS and the unused FOREACH_FUNCTION_ARGS_PTR
>>>>> macros.
>>>>>
>>>>> The few dozen (hundred?) existing uses of for loops that iterate
>>>>> over function parameter types using the TREE_CHAIN() macro can
>>>>> be relatively easily modified to adopt the iterator approach over
>>>>> time. (The patch stops of short of making this change.)
>>>>>
>>>>> Eventually, when GCC moves to more a recent C++ revision, it will
>>>>> become possible to simplify the for loops to make use of the range
>>>>> based for loop syntax along the lines of:
>>>>>
>>>>> for (auto argtype: function_args (functype))
>>>>> {
>>>>> ...
>>>>> }
>>>>>
>>>>> Tested on x86_64-linux, and (lightly) on powerpc64le-linux using
>>>>> a cross-compiler. I'll test the changes to the other back ends
>>>>> before committing.
>>>>
>>>> This isn't stage3 material.
>>>
>>> In the response referenced below Jeff requested I make use of
>>> iterators in my patch. This simply does what he asked for,
>>> except throughout all of GCC.
>>
>> I don't think he said you should invent new iterators - we have
>> existing ones.
>
> The patch doesn't add a new iterator: it makes the existing
> function_args_iterator a proper iterator class with the expected
> iterator members like increment and equality operator, to make
> it usable in contexts where other iterators (and pointers) are
> expected.
The way to go would have been to just use the existing iterator in your
patch and queue a gcc-10 change to a proper iterator.
