[llvm-bugs] [Bug 25669] New: Arbitrary overload resolution on template function instead of "ambiguous overload" error

via llvm-bugs llvm-bugs at lists.llvm.org
Sun Nov 29 12:35:34 PST 2015


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

            Bug ID: 25669
           Summary: Arbitrary overload resolution on template function
                    instead of "ambiguous overload" error
           Product: clang
           Version: 3.7
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: poletti.marco at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

The code below is a minimal code sample that exhibits the bug.
The type FindInMap<Map, int>::type should be `void' but Clang thinks it's
`char'.
This works correctly in GCC (tested version 4.8.5) but fails in Clang 3.7.0.

Explanation:
* The first overload of f (templated) is ambiguous (both Value=char and
Value=float match, with the same priority since both require a conversion from
Map* to the respective Pair<...>*) so it should be discarded.
* The second overload of f (non-templated) is the only one that remains and
therefore is the one that should be picked.

What's even more puzzling is that if the non-templated f is commented out, then
Clang displays the ambiguous overload error (which is correct) but for some
reason that's otherwise ignored.

template <typename T, typename U>
struct Pair {};

template <typename M, typename T>
struct FindInMap {
    template <typename Value>
    static Value f(Pair<T, Value>*);

    static void f(void*);

    using type = decltype(f((M*)0));
};

struct Map : public Pair<int, float>, Pair<int, char> {};

#include <functional> // Just for std::is_same
static_assert(std::is_same<FindInMap<Map, int>::type, void>::value, "");

-- 
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/20151129/653a04e4/attachment.html>


More information about the llvm-bugs mailing list