[patch] Fix pr16247

[Richard Smith]

On Mon, Jun 17, 2013 at 9:21 AM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Jun 11, 2013, at 6:02 AM, Rafael Espíndola <rafael.espindola at gmail.com>
> wrote:
>
> On 10 June 2013 19:08, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>
> Richard pointed out on IRC that the patch should look at the
> redeclaration context to avoid problems with one of the functions
> being in a extern "C++". Implementing that found some interesting
> problems. Consider
>
> extern "C" {
>  static void foo(int x);
>  static void foo() {
>  }
>  void foo(int x) {
>  }
> }
>
> This should be valid, since both functions have internal linkage and
> therefore none of them has C language linkage. Commenting the first
> declaration makes the code invalid as now the last one is extern C and
> [dcl.link] p6 kicks in. This means we have to do "normal" overload
> resolution first to see if the last decl we are looking at has C
> language linkage or not.
>
>
> BTW, is this sufficient evidence that we should just give static
> functions C language linkage? I just checked http://gcc.godbolt.org/
> and gcc 4.8 and icc 13 (which is edg based, no?), reject
>
> extern "C" {
>  static void foo() {
>  }
>  static void foo(int x) {
>  }
> }
>
> We are putting quiet a bit of effort to make sure we accept it and I
> still can't see the value.
>
>
> I, too, find this behavior strange. Changing between static and non-static
> shouldn’t affect whether a function can be overloaded; it’s completely
> non-intuitive and apparently at odds with existing practice in GCC/EDG.

The latter, at least, is not the case; EDG accepts this code in both
its compliant mode and in its g++-compatible mode. I'm surprised that
ICC rejects this. The former makes some degree of sense to me -- a
'static' declaration doesn't have external linkage and thus doesn't
have C linkage -- although I agree that it's weird.