[LLVMbugs] [Bug 9276] New: Checking declaration with multiple "auto"-declarators with one type-dependent initializer

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sun Feb 20 19:33:44 PST 2011


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

           Summary: Checking declaration with multiple "auto"-declarators
                    with one type-dependent initializer
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I stumbled over the following code during testing

template<typename T>
void f() {
  auto i = T(), j = 0;
}

int main() {
  f<long>();
  f<int>();
}

This code is ill-formed in the first instantiation, but the current
clang-with-auto does not reject it. Another question is what happens with the
second call.

We can compare the type deduced by "i" with the type deduced by "j" immediately
during parsing time, at which time "i" was deduced to type "T" and j to "int".
The two variable-types differ when declared and we raise a diagnostic. But we
can also wait until instantiation like done with so many other constructs,
because one type is dependent, and then compare the types. At that time, the
type of i and j are both "int". 

I think both ways are reasonable. GCC does it the first way, and says both
calls are ill-formed ("inconsistent deduction for 'auto': 'T' and then 'int'").
Don't know what the correct way to handle this is. 

I'm going to trust Doug who said I should make a PR so this can be fixed to
make the first one ill-formed and the second one working by comparing types at
instantiation time.

-- 
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.



More information about the llvm-bugs mailing list