[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