Skip to content
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

Closed
llvmbot opened this issue May 21, 2013 · 10 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla c++

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented May 21, 2013

Bugzilla Link 16088
Resolution FIXED
Resolved on Jan 20, 2017 07:26
Version trunk
OS All
Reporter LLVM Bugzilla Contributor
CC @DougGregor,@zmodem,@nico,@rnk,@Weverything,@Trass3r

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;

Foo(int i) : i(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:

  1. Rename the parameters, e.g. add a trailing underscore.

  2. 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).

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 21, 2013

assigned to @rnk

@rnk
Copy link
Collaborator

rnk commented Oct 21, 2014

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 {
int i;
Foo(int i) : i(i) { i++; } // modifies the parameter, not member
};

@rnk
Copy link
Collaborator

rnk commented Oct 21, 2014

*** Bug llvm/llvm-bugzilla-archive#21110 has been marked as a duplicate of this bug. ***

@Trass3r
Copy link
Contributor

Trass3r commented Feb 23, 2016

Yes this generates hundreds of useless warnings!
It should only warn if the name is used inside the constructor body.

@zmodem
Copy link
Collaborator

zmodem commented Feb 23, 2016

+rtrieu in case he's interested in this one

@Trass3r
Copy link
Contributor

Trass3r commented Feb 24, 2016

Function of interest is Sema::CheckShadow.

Something along the lines of:

Index: SemaDecl.cpp

--- SemaDecl.cpp (revision 260978)
+++ SemaDecl.cpp (working copy)
@@ -6344,10 +6344,18 @@
return;

// Fields are not shadowed by variables in C++ static methods.

  • if (isa(ShadowedDecl))
  • if (isa(ShadowedDecl)) {
    if (CXXMethodDecl *MD = dyn_cast(NewDC))
    if (MD->isStatic())
    return;

  • if (auto CD = dyn_cast(NewDC)) {

  •  if (dyn_cast<ParmVarDecl>(D)) {
    
  •    return;
    
  •  }
    
  • }

  • }

    if (VarDecl *shadowedVar = dyn_cast(ShadowedDecl))
    if (shadowedVar->isExternC()) {

@rnk
Copy link
Collaborator

rnk commented Mar 18, 2016

Here's something that kind of works but needs more extensive testing:
http://reviews.llvm.org/D18271

@rnk
Copy link
Collaborator

rnk commented Apr 29, 2016

r267957. If you want the old behavior, use -Wshadow-all.

@Trass3r
Copy link
Contributor

Trass3r commented Jan 20, 2017

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; }
int doBoo(int a, int f) { return a + f; }

@rnk
Copy link
Collaborator

rnk commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#21110

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 4, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++
Projects
None yet
Development

No branches or pull requests

4 participants