[llvm-bugs] [Bug 37159] New: Default argument evaluation for functions fails inside std::enable_if

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Apr 18 01:54:00 PDT 2018


            Bug ID: 37159
           Summary: Default argument evaluation for functions fails inside
           Product: clang
           Version: 6.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: attila.krasznahorkay at cern.ch
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

Created attachment 20194
  --> https://bugs.llvm.org/attachment.cgi?id=20194&action=edit
Source file demonstrating the issue


I've come across the following very recently, while trying to build a fairly
convoluted piece of code on MacOS, with Apple's clang 9.1 version. And then
checked that the exact same issue shows up with all versions of clang on Linux
that I could get my hands on. (3.9.1, 5.0.1, 6.0.0)

The issue is demonstrated by the attached, very synthetic and not too
meaningful example. (The setup in which I first saw this was a bit more
complicated...) When trying to compile the file in C++11 mode or higher, I get
the following build error from clang:

defaultArgProblem.cxx:14:29: error: use of default argument to function
'function1' that is declared later in class
   typename std::enable_if< function1(), int >::type function2() {
defaultArgProblem.cxx:11:45: note: default argument declared here
   static constexpr bool function1( int i = 1 ) { return i == number; }
defaultArgProblem.cxx:14:49: error: non-friend class member 'type' cannot have
a qualified name
   typename std::enable_if< function1(), int >::type function2() {
defaultArgProblem.cxx:14:53: error: expected ';' at end of declaration list
   typename std::enable_if< function1(), int >::type function2() {
3 errors generated.

While I'm able to compile the same source file with all the other compilers I
tried. (gcc-6.2.0, gcc-7.2.0 and icc-2018.)

Since nobody around me was aware of this issue previously, I thought it may be
useful to let you guys know about it. Of course we could work our way around
this, simply introducing an overload of the function in our original code that
receives no arguments. So it's by no means a serious problem for us. Still,
understanding it may be useful for the future.


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/20180418/a179bca0/attachment.html>

More information about the llvm-bugs mailing list