[patch] Fix pr16247

[Douglas Gregor]

On Jun 18, 2013, at 6:16 AM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Tue, Jun 18, 2013 at 5:47 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> > I also badgered the committee back in February when this last came up,
> > and no consensus for a language change appeared. I'm trying
> > rebadgering :)
> 
> Until then I think we should conform to what other compilers do and is
> less surprising to the users. This is not the same case as, for
> example, dependent bases, where the standard was not implemented by
> gcc and msvc at the time but was a better model than what those
> compilers implemented. Examples like:
> 
> extern "C" {
>   static void foo(int x);
>   static void foo() {
>   }
>   void foo(int x) {
>   }
> }
> 
> show are not adding value by being pedantically correct.
> 
> I am not sure I understand your suggestion about
> LocallyScopedExternCDecls. Consider a variant of the testcase above
> with just the last two functions. The foo(int) will be the fist extern
> C and overload resolution will decide we have an overload. We would
> have to walk the lookup results again to find foo().
> 
> Suppose overloading completely ignores whether a declaration is extern "C", and suppose you have a hashtable which returns the extern "C" decl for a given identifier.  After you conclude foo(int) overloads foo(), you look in the hashtable and say "oops, there was already a declaration with that name".  (I haven't really thought through whether this is a good idea.)


FWIW, this is almost certainly something we’ll have to do anyway, because we should detect conflicts when there are other extern “C” declarations that otherwise aren’t visible to name lookup, e.g.,

namespace N {
  extern "C" void foo(int);
}

namespace M {
  extern "C" void foo(float);
}

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130618/8b9de493/attachment.html>