[LLVMbugs] [Bug 15973] New: using directive picks wrong nearest enclosing namespace

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sun May 12 10:39:37 PDT 2013


http://llvm.org/bugs/show_bug.cgi?id=15973

            Bug ID: 15973
           Summary: using directive picks wrong nearest enclosing
                    namespace
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: fweimer at redhat.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

clang++ (default flags, trunk version) does not grok the following code:

namespace outer {
  void f(int &);
  void g();
  namespace inner {
    void f(long &);
  }
}

void
outer::g()
{
  using namespace outer::inner;
  int i;
  f(i);
  long l;
  f(l);
}

t.cpp:16:3: error: no matching function for call to 'f'
  f(l);
  ^
t.cpp:2:8: note: candidate function not viable: no known conversion from 'long'
to 'int &' for 1st argument
  void f(int &);
       ^ 
I looked up the rules, and the using directive should put the f(long &)
declaration in the outer namespace, like this:

namespace outer {
  void f(int &);
  void f(long &);
  void g();
}

void
outer::g()
{
   int i;
   f(i);
   long l;
   f(l);
}

(This follows from "During unqualified name lookup […], the names appear as if
they were declared in the nearest enclosing namespace which contains both the
using-directive and the nominated namespace." in [namespace.udir] in C++98.)

It seems that clang considers treats the global namespace as the nearest
enclosing namespace in this case, ignoring the namespace that is implied by the
function's declarator-id.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130512/3de1fd8a/attachment.html>


More information about the llvm-bugs mailing list