[cfe-commits] r147599 - in /cfe/trunk: include/clang/Basic/DiagnosticGroups.td include/clang/Basic/DiagnosticParseKinds.td include/clang/Sema/DeclSpec.h lib/Parse/ParseDecl.cpp test/CXX/basic/basic.link/p9.cpp test/CXX/dcl.dcl/basic.namespace/nam

[Richard Smith]

On Fri, January 6, 2012 01:49, David Blaikie wrote:
> That does seem a little overly restrictive to me. It's not an uncommon
> newbie mistake to add the empty parens for an object construction even on a
> trivial user defined type. The user then gets a fairly weird message in their
> use case about how they can't pass a foo(*)() as a foo (or worse, no overload
> is available, along with a big list of overload candidates). Providing a more
> likely warning before all this confusing noise seems really valuable.

For an on-by-default warning, it's a tricky balance between a desire for
essentially zero false positives and a desire for the warning to be as useful
as possible (and easy to explain). I'm not sure this latest change strikes the
right balance, but having slept on it I feel a little happier with this than
with warning on all (non-void) types; I've never seen anyone hit this on a
non-class type, and searching the web I can't find anyone complaining about it
for a non-class type. If you think also checking for typedef-names would help,
I'd have no objection to that change.

- Richard

> (at some point it'd be great to really improve the original most vexing
> parse warning too so it's produced on the really vexing cases in non-function
> scope (currently the warning doesn't fire at all there) and provide some nice
> fixit notes to fix the usual case ("foo f(bar())" -> "foo f((bar()))")))
> From: Richard Smith
> Sent: 1/5/2012 3:40 PM
> To: Argyrios Kyrtzidis
> Cc: cfe-commits at cs.uiuc.edu
> Subject: Re: [cfe-commits] r147599 - in /cfe/trunk:
> include/clang/Basic/DiagnosticGroups.td
> include/clang/Basic/DiagnosticParseKinds.td include/clang/Sema/DeclSpec.h
> lib/Parse/ParseDecl.cpp test/CXX/basic/basic.link/p9.cpp
> test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p11.cpp
> test/Misc/warning-flags.c test/SemaCXX/conditional-expr.cpp
> test/SemaCXX/decl-expr-ambiguity.cpp
> test/SemaTemplate/class-template-ctor-initializer.cpp On Thu, January 5, 2012
> 04:50, Argyrios Kyrtzidis wrote:
>
>> On Jan 4, 2012, at 8:12 PM, Richard Smith wrote:
>>
>>> Author: rsmith
>>> Date: Wed Jan  4 22:12:21 2012
>>> New Revision: 147599
>>>
>>>
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=147599&view=rev
>>> Log:
>>> PR10828: Produce a warning when a no-arguments function is declared in
>>> block scope, when no other indication is provided that the user intended
>>> to declare a function rather than a variable.
>>>
>>> Remove some false positives from the existing 'parentheses disambiguated
>>> as a function' warning by suppressing it when the declaration is marked as
>>>  'typedef'
>>> or 'extern'.
>>>
>>> Add a new warning group -Wvexing-parse containing both of these warnings.
>>>
>>>
>>>
>>> The new warning is enabled by default; despite a number of false
>>> positives (and
>>> one bug) in clang's test-suite, I have only found genuine bugs with it
>>> when running it over a significant quantity of real C++ code.
> [...]
>
>> 2) The new warning belongs in the sema, not the parser, because it requires
>>  semantic checks; consider the following case:
>>
>> void f() { typedef void VOID; VOID gg();  // false positive here. }
>>
>
> r147642. I've also restricted it to class types; I've not seen any instances
> of this for non-class types, and they're the types for which we can silently
> miss important RAII actions. I'd be happy to change this behavior if anyone
> has experience or evidence which points in a different direction.
>
> - Richard
>
>
> _______________________________________________
> cfe-commits mailing list cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>