I had to back out r313904, it causes lldb to assert on startup if you have a .lldbinit file

This actually asserts on any use "command source" is the one command that re-enters the command interpreter. It should be as simple as getting command source to rest the state flag before it goes to do the sourcing. I'll check that out tomorrow if nobody gets to it first.

command source is one of a set of early commands that we got into lldb before we had hired the person who wrote the testsuite way way back in the day, and though we went and backfilled the tests at that point, apparently we missed command source. So we'll also have to add a test for that.

I also filed:

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

to cover the issue.

Jim

Thank you Jim! I’m at cppcon and I won’t be able to work on it until Monday, but I can help with a code review if you’re planning to take a stab at it.

I was hoping we can avoid dealing with reentrancy but I was wrong. For handling reentrancy I was briefly considering either maintaining a full blown command stack or perhaps just a nesting counter.

Also, with reentrancy, I think that interruption should affect the “outmost” command scope rather than just interrupting the current command, what do you think?

We should probably have a stack that we can push and pop these states?

Thank you Jim! I'm at cppcon and I won't be able to work on it until Monday, but I can help with a code review if you're planning to take a stab at it.

Thanks. Not sure I'll get to this, but if I do I'll certainly put it up for review.

I was hoping we can avoid dealing with reentrancy but I was wrong. For handling reentrancy I was briefly considering either maintaining a full blown command stack or perhaps just a nesting counter.

Reentrancy into the command interpreter it is dicey at present because the CommandObjects weren't done quite right. At present, the CommandObject handles both specifying the logic of the command and it's inputs, AND is the storage for the current invocation's options. So you can only do things that might re-enter the interpreter after you've done all the reading of options you are likely to do. That hasn't been a big problem, but is kinda gross...

At some point, we need to add a CommandInvocation object that holds the option values for a given invocation. Then we can have a stack of invocations, which might be a natural place to organize this sort of thing as well.

I'm not implying that you should do this work, but sometimes having a future direction in mind will help your thinking.

In this light, I agree with Greg that a stack would be a good way to go. That's a beginning to model the more correct behavior of the interpreter.

Also, with reentrancy, I think that interruption should affect the "outmost" command scope rather than just interrupting the current command, what do you think?

If somebody does "command source" of a file with a bunch of commands, one of which is grinding away producing output, my intuition is that they would want to interrupt that one for sure. But trying to imagine using this, I think that for interrupting command source you would really want to roll all the way back out to giving the user control of the session. So my feeling is "both".

Jim