[llvm-bugs] [Bug 40329] New: Operator overload matching failure with enum as first operand

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40329

            Bug ID: 40329
           Summary: Operator overload matching failure with enum as first
                    operand
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Kevin.Bracey at arm.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Created attachment 21334
  --> https://bugs.llvm.org/attachment.cgi?id=21334&action=edit
Compilable example

The attached code using a C++98-compatible "SafeEnum" compiles and "works" with
all other compilers tried than clang. I say "works" because it isn't really
"safe", but it at least compiles.

In summary, we have

    template<typename Target, typename LayoutType = unsigned int>
    struct SafeEnum {
        /**
         * Type of the representation.
         */
        typedef LayoutType representation_t;

    /**
     * Construction of an enumeration value.
     */
        SafeEnum(LayoutType value) : _value(value) { }

        friend bool operator!=(SafeEnum lhs, SafeEnum rhs);
    };

    struct hci_error_code_t : SafeEnum<hci_error_code_t, uint8_t> {
        enum type {
            SUCCESS = 0x00
        };
        hci_error_code_t(type value);
        explicit hci_error_code_t(uint8_t raw_value);
    };

    hci_error_code_t hci_status;

Then, all compilers will accept 

    if (4 != hci_status) // so much for type safety
or 
    if (hci_status != hci_error_code_t::SUCCESS)


But clang alone will not accept

    if (hci_error_code_t::SUCCESS != hci_status)

It seems the overload using the argument conversion from hci_error_code_t::type
-> uint8_t -> SafeEnum<hci_error_code_t, uint8_t> isn't found if it's the first
argument, but is if it's the second.

Clearly the SafeEnum class doesn't do what is intended, and can be replaced by
`enum class`, but it seems something is off in clang's overload resolution - I
can find no reason in why argument order should matter here.

-- 
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/20190116/10a4f948/attachment.html>