[llvm-bugs] [Bug 46369] New: clang-cl incorrectly treats `long` and `int` as different types on LLP, but without overload priority

[via llvm-bugs]

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

            Bug ID: 46369
           Summary: clang-cl incorrectly treats `long` and `int` as
                    different types on LLP, but without overload priority
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mike.k at digitalcarbide.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

When building with `clang-cl`, the following code does not compile:

`
#include <type_traits>
#include <cstdio>
#include <cstdint>

#if _MSC_VER
using t_int = long;
using t_long = __int64;
#else
using t_int = int;
using t_long = long;
#endif

static const char * fn(int32_t) {
        return "int32";
}

static const char * fn(intptr_t) {
        return "intptr";
}

#define TEST(type) std::printf(#type " = %s\n", fn(type()))

int main() {
        TEST(t_int);
        TEST(t_long);
        return 0;
}
`

This appears to be due to `long` and `int` being entirely distinct types, and
thus not being treated as equivalent to either, and thus is an ambiguous
function call. 

While this is reasonable, under the Visual C++ compiler, this compiles fine,
and it calls the `int32_t` overload. While Visual C++ appears to also treat
`long` as a distinct type, it _also_ allows secondary implicit conversion to
`int` - that is, if you provide a `long` overload, it prefers that, but if you
provide `int` and something else but no `long`, it prefers `int`.

I'd expect `clang-cl` to give equivalent behavior for compatibility purposes.

-- 
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/20200617/4c2c03b8/attachment.html>