[llvm-bugs] [Bug 31110] New: Clang has pretty catastrophic failure of error recovery when a method's signature has an invalid type

[via llvm-bugs]

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

            Bug ID: 31110
           Summary: Clang has pretty catastrophic failure of error
                    recovery when a method's signature has an invalid type
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: chandlerc at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider this test case:
----
template<typename T> struct S {
  S() {}
  ~S() {}
  void foobar(U mumble) {}
};

class Base {
  S<int> dummy;
  int i;

public:
  virtual ~Base() {}
};

struct Derived : Base {
  virtual void method() {}
};

void test() {
  Derived d;

  Base *b = &d;
}
----

Clang, all the way back to 3.2, has really bad recovery for numerous cases like
this. At the very least:

1) Just because the member function is invalid, we mark all of the
instantiations of the class template invalid. This might be OK if doing that
effectively suppressed subsequent errors on that invalid class and we bailed
out of instantiation. But neither seems to be true.

2) In the face of an invalid member of a base class with a virtual destructor,
we manage to leave things in a state where essentially all of the errors and
warnings specific to the base <-> derived relationship are bogus.

The above test case only triggers this once, but in many cases, the above leads
a single root cause error to produce *hundreds* of diagnostics that have
literally nothing to do with anything connected to the class template that was
invalid.

-- 
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/20161122/aa4e016d/attachment-0001.html>