[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-08-11 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment. In https://reviews.llvm.org/D35941#838633, @rsmith wrote: > In https://reviews.llvm.org/D35941#823524, @alexfh wrote: > > > IIUC, most cases where -Wshadow warnings are issued is when a declaration > > from an enclosing scope would be accessible if there was no declaratio

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-08-10 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment. In https://reviews.llvm.org/D35941#823524, @alexfh wrote: > IIUC, most cases where -Wshadow warnings are issued is when a declaration > from an enclosing scope would be accessible if there was no declaration that > shadows it. In this case the the local variable of a fun

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-07-31 Thread Alexander Kornienko via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL309569: Fix -Wshadow false positives with function-local classes. (authored by alexfh). Repository: rL LLVM https://reviews.llvm.org/D35941 Files: cfe/trunk/lib/Sema/SemaDecl.cpp cfe/trunk/test/Se

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-07-28 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone accepted this revision. Quuxplusone added a comment. > But if I'm overseeing reasons to issue a warning in this case, we could add > an analogue of `-Wshadow-uncaptured-local` for this case. WDYT? I still think "any warning" is a marginally better UX than "no warning" on the particu

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-07-28 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision. rnk added a comment. This revision is now accepted and ready to land. > Another data point is that GCC doesn't warn in this case. That seems like a reasonable tie breaker when implementing these kinds of style-enforcement warnings. :) https://reviews.llvm.org/D35941

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-07-27 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment. In https://reviews.llvm.org/D35941#823020, @rnk wrote: > I'm not really sure this is a bug. The point of -Wshadow is to warn on valid > but possibly confusing code. Shadowing a variable is perfectly legal, but > people think it's confusing, so we implemented this warning

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-07-27 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment. I'm not really sure this is a bug. The point of -Wshadow is to warn on valid but possibly confusing code. Shadowing a variable is perfectly legal, but people think it's confusing, so we implemented this warning. Are we concerned that people might get confused between the di

[PATCH] D35941: Fix -Wshadow false positives with function-local classes.

2017-07-27 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh created this revision. Fixes http://llvm.org/PR33947. https://godbolt.org/g/54XRMT void f(int a) { struct A { void g(int a) {} A() { int a; } }; } 3 : :3:16: warning: declaration shadows a local variable [-Wshadow] void g(int a) {} ^ 1 : :1:12: note: previo