[PATCH] D44536: Avoid segfault when destructor is not yet known

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

It seems that we have two options: either we valiantly try to support this:

- we keep a list of types for which we've tried to form a //delete-expression//, but found that the type was incomplete
- when such a type is completed, we mark the destructor as used, triggering its synthesis or instantiation if necessary, and likewise for the `operator delete`
- we change our `CXXDeleteExpr` representation so that we don't store any information that might be changed by completing the class on the expression, such as the selected `OperatorDelete` function and whether we're performing a sized delete

... or we say that we're not interested in calling the destructor for code like this that has undefined behavior. The latter is certainly my preference; it seems hard to justify the complexity required to get this "right", especially since we still won't get it right in cases where we choose to emit some function definitions before the end of the TU.

I agree with John that tracking that we're in the "delete of incomplete class type" case (or some equivalent state, such as a "need to run a cleanup" flag) on the `CXXDeleteExpr` seems best. We should be careful to ensure that we rebuild the expression in template instantiation when the "delete of incomplete class type" flag is set, even if the expression is non-dependent, though. That is, I think this should work:

  struct X { ~X(); };
  struct A;
  A *get();
  template<int> void f() { delete (&get)(); }
  struct A { X x; };
  A *get() { return new A; }
  void g() { f<0>(); }

... even though we first form a (non-dependent) //delete-expression// for an `A` at a point where `A` is incomplete. (Note: the above example is carefully contrived to cause `TreeTransform` to reuse the `CXXDeleteExpr` from the template AST in the instantiation. Sadly the implicit array-to-pointer decay in the `CallExpr` is enough to cause it to rebuild rather than reuse...)


Repository:
  rC Clang

https://reviews.llvm.org/D44536