On Fri, Mar 18, 2016 at 11:08 AM, Reid Kleckner via cfe-commits < cfe-commits@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits