[PATCH] D18271: Avoid -Wshadow warnings about constructor parameters named after fields

[David Blaikie via cfe-commits]

On Fri, Mar 18, 2016 at 11:08 AM, Reid Kleckner via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> rnk added a comment.
>
> I'm not sure your example is in scope for -Wshadow, though. Any function
> call that takes a non-const reference to the parameter could modify it.


Sure - my argument is that we should whitelist the common cases & this is
one of them.

I'm not sure what implementation strategy you have in mind/which false
positives it would cause. I didn't have any particular strategy in mind
when I pointed out gap.

I guess I'm thinking something like:
>
>   void trim_in_place(std::string &s);
>   struct A {
>     std::string s;
>     A(std::string s) : s(s) { trim_in_place(s); }
>

Are you suggesting we should or shouldn't warn here? Seems like we should &
with your changes we don't.


>   };
>
> I think if we try to match that we'll have too many false positives.


I'm worried about false negatives around anything that isn't guaranteed to
change the parameter - that seems like we're opening a pretty big hole.


>
> I think your example would be better caught by something like -Wconsumed
> that looks for uses of objects that have been moved-from. That warning
> won't be confused by shadowing and will give a better diagnostic anyway.
>
>
> http://reviews.llvm.org/D18271
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160318/8f335516/attachment.html>