New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wshadow results in (correct, but unhelpful) warning with constructor parameter having the name of data member #16460
Comments
assigned to @rnk |
This has come up multiple times in LLDB coding style discussion and on chromium-dev. It'd also be nice if we could keep warning when there's ambiguity in the way that the ctor parameter is used, though, as in: struct Foo { |
*** Bug llvm/llvm-bugzilla-archive#21110 has been marked as a duplicate of this bug. *** |
Yes this generates hundreds of useless warnings! |
+rtrieu in case he's interested in this one |
Function of interest is Sema::CheckShadow. Something along the lines of: Index: SemaDecl.cpp--- SemaDecl.cpp (revision 260978) // Fields are not shadowed by variables in C++ static methods.
|
Here's something that kind of works but needs more extensive testing: |
r267957. If you want the old behavior, use -Wshadow-all. |
Much better now, thanks! Though it still warns about a similar pattern as some people don't use field name prefixes: void setFoo(Foo* f) { this->f = f; } |
mentioned in issue llvm/llvm-bugzilla-archive#21110 |
Extended Description
The following program results in a warning about the constructor parameter shadowing Foo's data member when compiled with clang r181693:
struct Foo {
int i;
};
This results in:
% clang++ -v -Wshadow -c clang.cpp
clang version 3.4 (trunk 181693)
[...]
clang.cpp:4:13: warning: declaration shadows a field of 'Foo' [-Wshadow]
Foo(int i) : i(i) {}
^
clang.cpp:2:9: note: previous declaration is here
int i;
^
1 warning generated.
While the warning is correct, it is IMHO a common idiom to name the constructor's parameters identical to the class's data member they initialize. In that case the warning is unhelpful.
Of course there are workarounds:
Rename the parameters, e.g. add a trailing underscore.
Use C++11's uniform initialization syntax where possible.
That is why I'm not sure if clang's current behavior should be changed (one possible change would be to only warn if the parameter is used in the constructor's body instead of only in the member initialization list).
The text was updated successfully, but these errors were encountered: