[cfe-commits] [patch] TransformIterator (motivating use case in Clang)

[David Blaikie]

On Tue, May 15, 2012 at 2:37 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Tue, May 15, 2012 at 3:33 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> > - Optimizing based on non-null-ness
>>
>> Clang doesn't optimize references on the basis of non-null-ness? For
>> those things that need to be reassigned, but are guaranteed to never
>> be null (I'm not sure we have (m)any of those - mostly if we're
>> reassigning them, they start out/may be null for some time)
>
> ...
>>
>> > - Still able to overwrite the argument within the funciton
>>
>> That usually seems to be a source of errors (as we've seen with people
>> thinking they have an out parameter & assigning to the parameter
>> directly, rather than the dereferenced parameter). Are there many
>> deliberate uses of this in Clang?
>
>
> Yes, this is a very common pattern:
>
> void foo(Decl *D) {
>   if (Decl *UnderlyingD = D->someWonkyMethod())
>     D = UnderlyingD;

Ah, right - I have seen a few of those. I think I only changed
(locally, not committed) one or two when I got bored at one point &
tried to push references further down through callers using the
filtering iterators (you can see that in another patch I attached to
the original review mail that Richard signed off on).