[llvm-commits] [lld] r172482 - /lld/trunk/lib/ReaderWriter/ELF/WriterELF.cpp

[Chandler Carruth]

On Mon, Jan 14, 2013 at 2:19 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Mon, Jan 14, 2013 at 2:10 PM, Nick Kledzik <kledzik at apple.com> wrote:
> > Author: kledzik
> > Date: Mon Jan 14 16:10:22 2013
> > New Revision: 172482
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=172482&view=rev
> > Log:
> > Fix shadowed variable warning
> >
> > Modified:
> >     lld/trunk/lib/ReaderWriter/ELF/WriterELF.cpp
> >
> > Modified: lld/trunk/lib/ReaderWriter/ELF/WriterELF.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/lld/trunk/lib/ReaderWriter/ELF/WriterELF.cpp?rev=172482&r1=172481&r2=172482&view=diff
> >
> ==============================================================================
> > --- lld/trunk/lib/ReaderWriter/ELF/WriterELF.cpp (original)
> > +++ lld/trunk/lib/ReaderWriter/ELF/WriterELF.cpp Mon Jan 14 16:10:22 2013
> > @@ -1542,10 +1542,10 @@
> >
> >    /// \brief find a absolute atom pair given a absolute atom name
> >    struct FindByName {
> > -    const std::string name;
> > -    FindByName(const StringRef name) : name(name) {}
> > +    const std::string _name;
>
> I'm not sure this is a shadowing variable warning we should bother
> fixing. If Clang is warning, we should fix Clang to suppress this case
> as it's a common idiom (but perhaps still catch cases where the
> parameter is referenced in the body of the ctor where, presumably, the
> user meant to mention the member instead). If GCC is warning & Clang
> isn't, we should consider just suppressing the GCC warning & relying
> on Clang's.
>

Yea... LLVM even follows this pattern pretty rigorously -- that is we
consistently try to name the constructor parameter and the member the same.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130114/65dcf91e/attachment.html>