[patch] Fix pr16247

[Richard Smith]

On 18 Jun 2013 09:45, "Douglas Gregor" <dgregor at apple.com> wrote:
>
>
> 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);
> }

Right. Not only is this something we need to handle regardless of this
particular bug, it's something we already do (we just get some of the
namespace scope cases wrong at the moment).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130618/600d8739/attachment.html>