[Bug c++/59256] New: qualified name in friend function declaration doesn't match previous declaration in inline namespace

[Bug c++/59256] New: qualified name in friend function declaration doesn't match previous declaration in inline namespace

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

            Bug ID: 59256
           Summary: qualified name in friend function declaration doesn't
                    match previous declaration in inline namespace
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org

I *think* this is valid, and clang accepts it, but G++ doesn't:

namespace detail {
  inline namespace v7 {
    void f();
  }
}

inline namespace v7 {
  template<typename T> class A {
  private:
    A() { }

    friend void detail::f();
  };
}

namespace detail {
  inline namespace v7 {
    void f() { A<int> a; }
  }
}

int main()
{
  detail::f();
}


$ g++ -std=gnu++11 n.cc
n.cc: In function ‘void detail::v7::f()’:
n.cc:10:5: error: ‘v7::A<T>::A() [with T = int]’ is private
     A() { }
     ^
n.cc:18:23: error: within this context
     void f() { A<int> a; }
                       ^


I think the qualified name detail::f should find ::detail::v7::f
>From gcc-bugs-return-435554-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 22 16:36:07 2013
Return-Path: <gcc-bugs-return-435554-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1312 invoked by alias); 22 Nov 2013 16:36:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1240 invoked by uid 48); 22 Nov 2013 16:36:04 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59257] New: usan/*san: Dpcumentation oddness of -fsanitize= / -fsanitize=shift
Date: Fri, 22 Nov 2013 16:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter cc
Message-ID: <bug-59257-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02331.txt.bz2
Content-length: 1374

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY257

            Bug ID: 59257
           Summary: usan/*san: Dpcumentation oddness of -fsanitize= /
                    -fsanitize=shift
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: documentation
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org, mpolacek at gcc dot gnu.org

Regarding -fsanitize=*

That option does not appear in
http://gcc.gnu.org/onlinedocs/gcc/Option-Index.html but I think it should.

Actually, I think several other options miss a @opindex entry, too.


Additionally, in the man page, I get:

       -fsanitize=undefined
           Enable UndefinedBehaviorSanitizer, a fast undefined
           behavior detector.  Various computations will be
           instrumented to detect undefined behavior at runtime.
           Current suboptions are:

           *<-fsanitize=shift>
               This option enables checking that the result of a

The < > look odd.


In invoke.texi, one has:

@item -fsanitize=undefined
...
  @item @option{-fsanitize=shift}


Maybe there shouldn't be an @option{}?

It does look okay at http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-22
                 CC|                            |jason at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
I understand this affects the library in a pretty serious way
(http://gcc.gnu.org/ml/libstdc++/2013-11/msg00128.html) let's raise the
priority and add Jason in CC.

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Uh, just rediscovered this and recreated exactly the same reduced testcase!

Also, this variation which should not compile (because lookup should fail for
N::f):

namespace N
{
  namespace detail
  {
    inline namespace ver
    {
      template<typename T>
        void f();
    }
  }

  template<typename T>
    void
    detail::f() { }
}

int main()
{
  N::f<int>();
}

Somehow the fact N::detail::ver is an inline namespace causes N::detail::f to
also be declared in N.

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[georg@schorsch-tech.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

georg@schorsch-tech.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |georg@schorsch-tech.de

--- Comment #5 from georg@schorsch-tech.de ---
Created attachment 35665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35665&action=edit
tried backport of 217461 to 4.9.2

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[georg@schorsch-tech.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

--- Comment #6 from georg@schorsch-tech.de ---
ups ... wrong bug .. please delete that submitted patch

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[herring at lanl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

S. Davis Herring <herring at lanl dot gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |herring at lanl dot gov

--- Comment #14 from S. Davis Herring <herring at lanl dot gov> ---
(In reply to Jonathan Wakely from comment #0)
> I think the qualified name detail::f should find ::detail::v7::f

In case it helps, this is now unambiguously the case ([decl.meaning]/2.2 in the
current draft describes the lookup, but here it's just ordinary qualified
lookup).

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2021-12-13 00:00:00         |2023-9-12

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This affects std::format now too.

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The std::format case looks like this:

namespace x
{
  inline namespace v {

    namespace detail {
      template<class> struct bar;
    }

    template<class Arg>
      auto make(Arg);

    template<class T>
    class detail::bar {
      bar() { }

      template<class Arg>
        friend auto x::make(Arg);
    };

    template<class Arg>
      auto make(Arg)
      {
        detail::bar<Arg> b;
        return 1;
      }
  }
}
int main()
{
  return x::make(1);
}