From: Guinevere Larsen <blarsen@redhat.com>
To: Andrew Burgess <aburgess@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v3] gdb/testsuite: fix completion tests when using READ1
Date: Wed, 8 Nov 2023 17:10:24 +0100 [thread overview]
Message-ID: <d83933c2-206b-115e-4024-7e265bf1b77c@redhat.com> (raw)
In-Reply-To: <87cywlu12v.fsf@redhat.com>
On 07/11/2023 14:47, Andrew Burgess wrote:
> Guinevere Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> The commit a3da2e7e550c4fe79128b5e532dbb90df4d4f418 has introduced
>> regressions when testing using the READ1 mechanism. The reason for that
>> is the new failure path in proc test_gdb_complete_tab_unique, which
>> looks for GDB suggesting more than what the test inputted, but not the
>> correct answer, followed by a white space. Consider the following case:
>>
>> int foo(int bar, int baz);
>>
>> Sending the command "break foo<tab>" to GDB will return
>>
>> break foo(int, int)
>>
>> which easily fits the buffer in normal testing, so everything works, but
>> when reading one character at a time, the test will find the partial
>> "break foo(int, " and assume that there was a mistake, so we get a
>> spurious FAIL.
>>
>> That change was added because we wanted to avoid forcing a completion
>> failure to fail through timeout, which it had to do because there is no
>> way to verify that the output is done, mostly because when I was trying
>> to solve a different problem I kept getting reading errors and testing
>> completion was frustrating.
>>
>> This commit implements a better way to avoid that frustration, by first
>> testing gdb's complete command and only if that passes we will test tab
>> completion. The difference is that when testing with the complete
>> command, we can tell when the output is over when we receive the GDB
>> prompt again, so we don't need to rely on timeouts. With this, the
>> change to test_gdb_complete_tab_unique has been removed as that test
>> will only be run and fail in the very unlikely scenario that tab
>> completion is different than command completion.
>> ---
>> gdb/testsuite/lib/completion-support.exp | 31 +++++++++++++++---------
>> 1 file changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/gdb/testsuite/lib/completion-support.exp b/gdb/testsuite/lib/completion-support.exp
>> index fdc512838c3..56c0eee8e1d 100644
>> --- a/gdb/testsuite/lib/completion-support.exp
>> +++ b/gdb/testsuite/lib/completion-support.exp
>> @@ -111,15 +111,11 @@ proc test_gdb_complete_tab_unique { input_line complete_line_re append_char_re }
>>
>> set test "tab complete \"$input_line\""
>> send_gdb "$input_line\t"
>> - set partial_complete [string_to_regexp $input_line]
>> set res 1
>> gdb_test_multiple "" "$test" {
>> -re "^$complete_line_re$append_char_re$" {
>> pass "$test"
>> }
>> - -re "$partial_complete\[^ \]+ $" {
>> - fail "$test"
>> - }
>> timeout {
>> fail "$test (timeout)"
>> set res -1
>> @@ -194,17 +190,21 @@ proc test_gdb_complete_cmd_none { line } {
>> proc test_gdb_complete_cmd_unique { input_line complete_line_re } {
>> global gdb_prompt
>>
>> + set res 0
>> set cmd "complete $input_line"
>> set cmd_re [string_to_regexp $cmd]
>> set test "cmd complete \"$input_line\""
>> gdb_test_multiple $cmd $test {
>> -re "^$cmd_re\r\n$complete_line_re\r\n$gdb_prompt $" {
>> pass $test
>> + set res 1
>> }
>> -re "$gdb_prompt $" {
>> fail "$test"
>> + set res -1
>> }
>> }
>> + return $res
>> }
>>
>> # Test that completing "CMD_PREFIX + COMPLETION_WORD" with the
>> @@ -263,12 +263,6 @@ proc test_gdb_complete_none { input_line } {
>>
>> proc test_gdb_complete_unique_re { input_line complete_line_re {append_char " "} {max_completions 0}} {
>> set append_char_re [string_to_regexp $append_char]
>> - if { [readline_is_used] } {
>> - if { [test_gdb_complete_tab_unique $input_line $complete_line_re \
>> - $append_char_re] == -1 } {
>> - return -1
>> - }
>> - }
>>
>> # Trim COMPLETE LINE, for the case we're completing a command with leading
>> # whitespace. Leading command whitespace is discarded by GDB.
>> @@ -288,7 +282,22 @@ proc test_gdb_complete_unique_re { input_line complete_line_re {append_char " "}
>> "\r\n$input_line_re $max_completion_reached_msg_re"
>> }
>>
>> - test_gdb_complete_cmd_unique $input_line $expected_output_re
>> + # First test completion with the command, then with tab.
>> + # It is done in this order because cmd_complete knows when the output
>> + # from GDB is over, so it can fail without requiring a timeout, which
>> + # speeds up testing if necessary.
>> +
>> + if { [test_gdb_complete_cmd_unique $input_line\
>> + $expected_output_re] == -1 } {
>> + return -1
>> + }
> This doesn't seem right. Or at least, it's not really inline with how
> the return value from this proc is used.
>
> Check out `test_complete_prefix_range_re`. In here you can see that a
> return value of -1 is used to indicate that a test in
> test_gdb_complete_unique_re timedout, while here you're using it to
> indicate general failure.
That's fair, I should have looked around before deciding.
>
> I would suggest that `test_gdb_complete_cmd_unique` should simply return
> true/false to indicate if the test passed or failed (for any reason).
> Then in `test_gdb_complete_unique_re` you can just:
>
> if { ![test_gdb_complete_cmd_unique $input_line\
> $expected_output_re] } {
> return 0
> }
>
> The users of `test_gdb_complete_unique_re` can then continue to see -1
> as the timeout indicator.
>
> Of course, you could have test_gdb_complete_cmd_unique return -1 on
> timeout, but I suspect a timeout here is much less likely, so maybe the
> extra complexity of catching this case isn't worth the effort? I don't
> think I'd bother, but you might feel different.
I think its easy enough to implement the timeout warning, and this way
its there if anyone wants to use it. I'll do this on v4
--
Cheers,
Guinevere Larsen
She/Her/Hers
>
> Thanks,
> Andrew
>
>
>
>
>
>
>> +
>> + if { [readline_is_used] } {
>> + if { [test_gdb_complete_tab_unique $input_line $complete_line_re \
>> + $append_char_re] == -1 } {
>> + return -1
>> + }
>> + }
>> return 1
>> }
>>
>> --
>> 2.41.0
next prev parent reply other threads:[~2023-11-08 16:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 11:30 Guinevere Larsen
2023-09-14 13:02 ` [PING][PATCH " Guinevere Larsen
2023-10-13 15:26 ` [PINGv2][PATCH " Guinevere Larsen
2023-10-16 23:48 ` [PATCH " Thiago Jung Bauermann
2023-10-24 15:58 ` [Pingv3] " Guinevere Larsen
2023-11-07 13:02 ` [Ping v4] " Guinevere Larsen
2023-11-07 13:47 ` Andrew Burgess
2023-11-08 16:10 ` Guinevere Larsen [this message]
2023-11-08 16:56 ` [PATCH v4] " Guinevere Larsen
2023-11-13 11:28 ` Andrew Burgess
2023-11-14 10:40 ` Guinevere Larsen
2023-11-22 9:44 ` [PATCH v5] " Guinevere Larsen
2023-11-29 15:25 ` Andrew Burgess
2023-12-01 12:31 ` Guinevere Larsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d83933c2-206b-115e-4024-7e265bf1b77c@redhat.com \
--to=blarsen@redhat.com \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).