[Lldb-commits] [PATCH] D75418: tab completion for process signal

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

I think this is just a bug in argument completion.

The CommandInterpreter needs to sync up with the currently selected target/process/thread/frame before running commands.

It COULD do that by having every API that changes the selected T/P/T/F above notify the CommandInterpreter of the change.  Then you would only need UpdateExecutionContext when you want to override the currently selected context.  You do that, for instance, when you run stop hooks or breakpoint commands, which don't actually select the context they operate on.

But it doesn't do it that way.  Instead, the CommandInterpreter is responsible for syncing its state before running commands.  It calls UpdateExecutionContext on each command evaluation, either passing along an override context as above, or sending in a nullptr to tell it to sync with the currently selected state.

However, HandleCompletions doesn't do that, so it might not be operating on a consistent state.  To be consistent, it really should do that as well.

This is actually a bug in the other completions that actually depend on a selected entity.  For instance, run a program to a breakpoint and before doing anything else do: `frame var l<TAB>` and you won't get anything, but then do just `frame var` and then `frame var l<TAB>` and then you will get all the locals starting with `l`...  You wouldn't generally notice this, any other command you issued after stopping would have sync'ed up the state.  So it only happens when `frame var l<TAB>` is the FIRST thing you do after a stop.

Seems like the correct fix is to have HandleCompletions call UpdateExecutionContext, rather than having individual completions call it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75418/new/

https://reviews.llvm.org/D75418