Per [except.handle]p10, the handler for a constructor or destructor function-try-block cannot refer to a non-static member of the object under construction. This patch adds a new clang-tidy check that warns the user when they've hit this undefined behavior.
Due to how infrequent function-try-blocks appear on constructors and destructors in the wild compared to how often member expressions are encountered, I felt this was more appropriate as a clang-tidy check than as a semantic warning. I was concerned with efficiency of checking whether an arbitrary member expression was referring to the object under construction/destruction within the function-try-block catch handler scope.
This patch corresponds to the CERT secure coding rule ERR53-CPP (https://www.securecoding.cert.org/confluence/display/cplusplus/ERR53-CPP.+Do+not+reference+base+classes+or+class+data+members+in+a+constructor+or+destructor+function-try-block+handler)
Maybe convert from a do-while into a while loop (or even a for loop)? We might not be in a function at all (for instance, we might be in a default member initializer), and that would let us bail out earlier in that case.