msvc 14 generates new warnings that occurr in just about every llvm source file

Yaron Keren yaron.keren at gmail.com
Fri Aug 1 07:01:13 PDT 2014


If I understand these warning correctly (they are not documented on MS web
site yet), they warn about local variable  shadowing some other definition.
If so, none are good to suppress, to the contrary, these new warnings are
likely to expose bugs in the current codebase.

Shadow situations cause very confusing bugs. We have long functions in
clang, for instance Sema::ClassifyName is about 300 lines. If I need to
modify this function, I glance at its header and see Scope *S. I would
expect S refer to the input paramater all along the function, rather being
shadowed by some local variable. I can check with VS goto declaration what
II refers to but why? I've seen it's an input parameter, right? name
shadowing is a trap.

Yaron



2014-08-01 15:28 GMT+03:00 Aaron Ballman <aaron at aaronballman.com>:

> > From bffa68240130a2cef732d24be259e9523266e67c Mon Sep 17 00:00:00 2001
> > From: Oliver Schneider <oliver.schneider at kit.edu>
> > Date: Fri, 1 Aug 2014 11:46:32 +0200
> > Subject: [PATCH] ignore new verbose warnings on MSVC 14
> >
> > ---
> >  cmake/modules/HandleLLVMOptions.cmake | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/cmake/modules/HandleLLVMOptions.cmake
> b/cmake/modules/HandleLLVMOptions.cmake
> > index 8258512..2c6b56d 100644
> > --- a/cmake/modules/HandleLLVMOptions.cmake
> > +++ b/cmake/modules/HandleLLVMOptions.cmake
> > @@ -245,6 +245,9 @@ if( MSVC )
> >      -wd4345 # Suppress 'behavior change: an object of POD type
> constructed with an initializer of the form () will be default-initialized'
> >      -wd4351 # Suppress 'new behavior: elements of array 'array' will be
> default initialized'
> >      -wd4355 # Suppress ''this' : used in base member initializer list'
> > +    -wd4456 # Suppress 'declaration of 'variable_name' hides previous
> local declaration'
> > +    -wd4457 # Suppress 'declaration of 'variable_name' hides function
> parameter'
>
> These make sense to suppress, I think.
>
> > +    -wd4458 # Suppress 'declaration of 'variable_name' hides class
> member'
>
> This one has me slightly worried. How often does this warning happen
> in practice?
>
> >      -wd4503 # Suppress ''identifier' : decorated name length exceeded,
> name was truncated'
> >      -wd4624 # Suppress ''derived class' : destructor could not be
> generated because a base class destructor is inaccessible'
> >      -wd4722 # Suppress 'function' : destructor never returns, potential
> memory leak
> > --
> > 1.8.5.2.msysgit.0
> >
>
> Thanks!
>
> ~Aaron
>
> On Fri, Aug 1, 2014 at 6:48 AM, oliver <llvm6549 at oli-obk.de> wrote:
> > Sorry, new attachment, i just noticed there's one more relevant message
> + i
> > didn't add it in the correct order as the other warnings were
> >
> > Am 01.08.2014 12:37, schrieb oliver:
> >
> > Hi,
> >
> > attached is a small patch that adds 2 more warnings to the MSVC warning
> > ignore list
> >
> > greetings
> >
> > /oliver
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140801/4f08e8da/attachment.html>


More information about the llvm-commits mailing list