Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

[QOI] warn about free functions which shadow one in a namespace #3654

Open Quuxplusone opened 14 years ago

Quuxplusone commented 14 years ago
Bugzilla Link PR6367
Status NEW
Importance P enhancement
Reported by Daniel Dunbar (daniel@zuster.org)
Reported on 2010-02-21 13:08:55 -0800
Last modified on 2011-05-24 09:52:25 -0700
Version unspecified
Hardware PC All
CC dgregor@apple.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
I would like clang to optionally warn me about 'f0' in this:
--
ddunbar@giles:tmp$ cat t.cpp
void f1();
namespace foo {
  void f0();
  void f1();
}
void f0() {} // expected-warning {{something nice}}
void f1() {}
ddunbar@giles:tmp$ clang -Wall -c t.cpp
ddunbar@giles:tmp$
--

I almost never care to implement a non-static, undeclared function. I want
clang to point out that I am doing this when it can find a 'f0' inside a
different namespace. I want a fixit for adding 'foo::'.
Quuxplusone commented 14 years ago

It's kind of like -Wmissing-prototypes for C++. It should not apply to templates or member functions.

Quuxplusone commented 13 years ago
A related case:

struct S {
  void f() const;
  int n;
};

void f() const {
  n = 0;
}

It'd be amazing if clang could suggest adding "S::" to this function
definition. This case is arguably easier, since an ill-formed cv-qualifier (or
ref-qualifier) on a function definition is a big giveaway that it was meant to
be a member function: we can give an error with a fixit here, whereas the
namespace case would have to be just a warning (with a fixit in a note).

We can make this check faster (and weed out false positives) by only looking in
classes and namespaces for which we've already seen at least one out-of-line
function definition in this TU.