[LLVMbugs] [Bug 19160] New: failure to diagnose ambiguity in conditional between glvalue and prvalue

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Mar 17 00:34:34 PDT 2014


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

            Bug ID: 19160
           Summary: failure to diagnose ambiguity in conditional between
                    glvalue and prvalue
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            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:

struct B;
struct A { A(); A(B&) = delete; operator B&(); };
struct B : A {} b;
B &c = true ? A() : b;

The A prvalue converts to a B lvalue, and the B lvalue satisfies the rules for
converting to an A prvalue. 5.16/3 bullet 3 bullet 1 is clear that we only
actually copy-initalize a temporary of type A from 'b' "if the conversion is
applied", which it isn't in this case, because we hit the ambiguity first.

So we should reject this due to ambiguity, instead of accepting it and picking
the non-deleted conversion sequence. Both GCC and EDG reject.


Here's a more exciting case:

struct B;
struct A { A(); A(B&); operator B&() = delete; };
struct B : A {} b;
B &c = true ? A() : b;

Here, we should either claim ambiguity or convert 'b' to an A prvalue
(depending on whether the "can be implicitly converted" check in 5.16/3 bullet
1 cares about deletedness or not) -- the standard is not clear which (and a
literal reading suggests this way round is valid!); we convert the 'A'
temporary to a B lvalue!

-- 
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/20140317/30468ca3/attachment.html>


More information about the llvm-bugs mailing list