If you hit a breakpoint while running an expression we don't want to run other commands that might end up running expressions again because that doesn't currently work recursively. But the code that was checking there was checking "WasTheLastResumeForUserExpression" which isn't quite right, since that expression might have already completed - because it was part of the handling of the breakpoint before we got to the StopInfo. We are tracking whether we are currently running an expression, however, which is the correct thing to check. So I made a function to check that and changed the StopInfoBreakpoint to use it.
It's actually pretty hard to get into a situation where this causes problems, because the expression has to happen internally in lldb between the stop and the fetching of the stop event. However, that's just what the objc_exception_throw frame recognizer does. Some code that was added to the StopInfoBreakpoint turned this "oops I'm running an expression" into a resume - which was necessary for some Windows fix, but caused us to fail to stop for the objc_exception_throw breakpoint.
So I added a test for the built-in objc_exception_throw built-in recognizer. Without the fix the test would fail because we didn't stop at the exception throw point. This also tests that we got all the values right.
I would prefer IsRunningExpression for consistency with other IsFoo methods. It still conveys that the process is in the process of executing an expression. /end bikeshedding