[LLVMbugs] [Bug 14178] New: Parse ambiguity with a default member function argument, where the default value comes from a template

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=14178

             Bug #: 14178
           Summary: Parse ambiguity with a default member function
                    argument, where the default value comes from a
                    template
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: cliffy+llvm.bugs at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9416
  --> http://llvm.org/bugs/attachment.cgi?id=9416
Source code exhibiting bug; use "-DBAD" to induce the failure.

I've written some code where a member function takes an argument with a default
value, and the default value comes from a templated automatic class object. 
The parser grabs the shortest plausible default expression, but this turns out
to be only the first three tokens "TwidGen<N" of the default expression.  This
fails, as the rest of the template expression ends up looking like garbage. 
Adding a pair of parentheses around the default value fixes the problem.  FWIW,
g++ is able to parse this code correctly.  

The offending line looks like:
    apply (const COMPLEX *src, TWIDARRAY twids =  TwidGen<N, COMPLEX>() ) {...}
and the correction looks like:
    apply (const COMPLEX *src, TWIDARRAY twids = (TwidGen<N, COMPLEX>())) {...}

So in the broken code, the expression "TwidGen<N" is parsed as the initializer
and the comma after "N" is incorrectly treated as the separator between
arguments to "apply".  The correct interpretation is that the entire
"TwidGen<N, COMPLEX>()" sequence is the default value.  

There's a hint in the error messages from LLVM: 
clang_bad.cpp:21:5: note: candidate function template not viable: requires 3
arguments, but 1 was
      provided
    apply (const COMPLEX *src, 
    ^
The compiler thinks that apply() takes three arguments, not two.

It's possible that this falls into the set of known issues where C++ is hard
(undecidable?) to parse.  I couldn't find the relevant parts of the standard to
figure out whether this is the case, and what the appropriate/approved response
is.  

I've attached my minimized source file.  Add -DBAD to get the failure to occur;
the corrected source code is the default.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.