[LLVMbugs] [Bug 12583] declval() with incomplete type

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Apr 17 22:40:40 PDT 2012


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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |INVALID

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-04-18 00:40:40 CDT ---
When two compilers tell you your code is broken, it probably is. Note the
diagnostic is pointing at the comma between the two declval expressions.
Because the right-hand declval expression has class type, we perform
argument-dependent lookup at template instantiation time to find an overloaded
'operator,'. Now, because the left-hand declval expression has type
'x_pair<int, Incomplete>*', 'x_pair<int, Incomplete>' is an associated class.
Therefore we instantiate 'x_pair<int, Incomplete>' in case it contains the
definition of a friend 'operator,', and that instantiation is ill-formed.

Reduced testcase:

struct incomplete;
struct true_type {};
template<typename T> struct wrap { T value; };
typedef wrap<incomplete> *ptr;
decltype(ptr(), true_type()) x;

Note that if...

friend void operator,(wrap*, true_type);

... were added to wrap, it would be used in the decltype expression.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list