[LLVMbugs] [Bug 16082] New: may need to parse class member function bodies out-of-order

[bugzilla-daemon at llvm.org]

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

            Bug ID: 16082
           Summary: may need to parse class member function bodies
                    out-of-order
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider this:

  template<typename T, T v> struct ic {};

  template<typename Type>
  class Test
  {
  public:
    constexpr Test(const Type val) : _value(val) {}
//  constexpr Type get() const {return _value;} // #1
    static void test() {
      static constexpr Test<int> x(42);
      ic<int, x.get()> i;
    }
    constexpr Type get() const {return _value;} // #2
  protected:
    Type _value;
  };

  void f() { Test<int>::test(); }

With #1 uncommented, both g++ and Clang accept. With #2 uncommented, both
reject (because we've not yet parsed the body of Test::get when we try to
instantiate it within the non-dependent constant expression 'x.get()'). EDG
accepts either way, and this code does not seem to be obviously ill-formed.
Perhaps we should trigger parsing of a member function body (a la
-fdelayed-template-parsing) if it's needed from another member function's body?

On the other hand, even EDG rejects this:

  struct A {
    void f() {
      static_assert(g(), "");
    }
    static constexpr bool g() { return true; } 
  };

... which we could accept with the same technique.

-- 
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/20130521/96b3f3aa/attachment.html>