diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-11-16 14:42:56 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-11-27 15:44:45 +0000 |
commit | 935dc9ff652ca256c10672412c1df3da95cadbfb (patch) | |
tree | 33bda9adff1104c207ef6194840f60cdd5cb7292 /gdb/python/py-cmd.c | |
parent | cd51849c90e8fd13779bec69f5d4c7aadf03a532 (diff) | |
download | gdb-935dc9ff652ca256c10672412c1df3da95cadbfb.zip gdb-935dc9ff652ca256c10672412c1df3da95cadbfb.tar.gz gdb-935dc9ff652ca256c10672412c1df3da95cadbfb.tar.bz2 |
gdb/python: handle completion returning a non-sequence
GDB's Python API documentation for gdb.Command.complete() says:
The 'complete' method can return several values:
* If the return value is a sequence, the contents of the
sequence are used as the completions. It is up to 'complete'
to ensure that the contents actually do complete the word. A
zero-length sequence is allowed, it means that there were no
completions available. Only string elements of the sequence
are used; other elements in the sequence are ignored.
* If the return value is one of the 'COMPLETE_' constants
defined below, then the corresponding GDB-internal completion
function is invoked, and its result is used.
* All other results are treated as though there were no
available completions.
So, returning a non-sequence, and non-integer from a complete method
should be fine; it should just be treated as though there are no
completions.
However, if I write a complete method that returns None, I see this
behaviour:
(gdb) complete completefilenone x
Python Exception <class 'TypeError'>: 'NoneType' object is not iterable
warning: internal error: Unhandled Python exception
(gdb)
Which is caused because we currently assume that anything that is not
an integer must be iterable, and we call PyObject_GetIter on it. When
this call fails a Python exception is set, but instead of
clearing (and therefore ignoring) this exception as we do everywhere
else in the Python completion code, we instead just return with the
exception set.
In this commit I add a PySequence_Check call. If this call returns
false (and we've already checked the integer case) then we can assume
there are no completion results.
I've added a test which checks returning a non-sequence.
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python/py-cmd.c')
-rw-r--r-- | gdb/python/py-cmd.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/python/py-cmd.c b/gdb/python/py-cmd.c index 20a384d..d3845fc 100644 --- a/gdb/python/py-cmd.c +++ b/gdb/python/py-cmd.c @@ -290,7 +290,7 @@ cmdpy_completer (struct cmd_list_element *command, else if (value >= 0 && value < (long) N_COMPLETERS) completers[value].completer (command, tracker, text, word); } - else + else if (PySequence_Check (resultobj.get ())) { gdbpy_ref<> iter (PyObject_GetIter (resultobj.get ())); |