[LLVMbugs] [Bug 15628] New: parser crash for overloaded operator++ and ?:

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Mar 29 14:47:19 PDT 2013


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

            Bug ID: 15628
           Summary: parser crash for overloaded operator++ and ?:
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: llvm at brianandresen.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10257
  --> http://llvm.org/bugs/attachment.cgi?id=10257&action=edit
test case

Clang 3.2 crashed while parsing some code, which compiles okay using GCC 4.7.2
and Visual Studio 2010/2012.

I distilled out a simpler test case.  The key problem seems to be an expression
with an overloaded operator++, given directly as the guard expression for the
ternary operator ?:.  I found several workarounds, described below.

---

class BlockInputIter
{
public:
  void* operator++(int);
  void* next();
};


bool f()
{
  BlockInputIter nextInput;
  return nextInput++ ? false : true;  // *** clang 3.2 parser failure ***
}

// Adding an explicit comparison to 0 is a workaround.
bool workaround1()
{
  BlockInputIter nextInput;
  return ( nextInput++ != 0 ) ? false : true;
}

// Even just adding parentheses around the "nextInput++" expression works.
bool workaround2()
{
  BlockInputIter nextInput;
  return ( nextInput++ ) ? false : true;
}

// If a function is used, instead of an operator overload, there's no problem.
bool workaround3()
{
  BlockInputIter nextInput;
  return nextInput.next() ? false : true;
}

-- 
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/20130329/6738cdb5/attachment.html>


More information about the llvm-bugs mailing list