[llvm-bugs] [Bug 25513] New: is_constructible<int (int)> should be false

[via llvm-bugs]

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

            Bug ID: 25513
           Summary: is_constructible<int (int)> should be false
           Product: clang
           Version: 3.7
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sfinae at hotmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 15283
  --> https://llvm.org/bugs/attachment.cgi?id=15283&action=edit
self contained repro

Function types shouldn't be considered constructible (unless I am completely
confused).

C:\Temp>type meow.cpp
template <typename T, typename... Args> struct is_constructible {
    static constexpr bool value = __is_constructible(T, Args...);
};

template <typename T, typename... Args> struct is_nothrow_constructible {
    static constexpr bool value = __is_nothrow_constructible(T, Args...);
};

template <typename T, typename... Args> struct is_trivially_constructible {
    static constexpr bool value = __is_trivially_constructible(T, Args...);
};

static_assert(!          is_constructible<int (int)>::value, "BOOM");
static_assert(!  is_nothrow_constructible<int (int)>::value, "BOOM");
static_assert(!is_trivially_constructible<int (int)>::value, "BOOM");

/***
N4527 20.10.4.3 [meta.unary.prop]/7:

Given the following function declaration:

template <class T>
  add_rvalue_reference_t<T> create() noexcept;

the predicate condition for a template specialization is_constructible<T,
Args...>
shall be satisfied if and only if the following variable definition would be
well-formed for some invented variable t:

T t(create<Args>()...);

[ Note: These tokens are never interpreted as a function declaration. -end note
]
Access checking is performed as if in a context unrelated to T and any of the
Args.
Only the validity of the immediate context of the variable initialization is
considered.
[ Note: The evaluation of the initialization can result in side effects such as
the
instantiation of class template specializations and function template
specializations,
the generation of implicitly-defined functions, and so on. Such side effects
are not
in the "immediate context" and can result in the program being ill-formed. -end
note ]
***/

C1XX accepts:

C:\Temp>cl /EHsc /nologo /W4 /c meow.cpp
meow.cpp

But Clang/C2 rejects:

C:\Temp>clang-cl /EHsc /nologo /W4 /c meow.cpp
meow.cpp(13,1) :  error: static_assert failed "BOOM"
static_assert(!          is_constructible<int (int)>::value, "BOOM");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
meow.cpp(14,1) :  error: static_assert failed "BOOM"
static_assert(!  is_nothrow_constructible<int (int)>::value, "BOOM");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
meow.cpp(15,1) :  error: static_assert failed "BOOM"
static_assert(!is_trivially_constructible<int (int)>::value, "BOOM");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.

This is NOT specific to Clang/C2 - http://melpon.org/wandbox/ also rejects. The
same thing happens if libc++ <type_traits> is used instead of the compiler
hooks used above.

-- 
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/20151113/295eb8ee/attachment.html>