summaryrefslogtreecommitdiff
path: root/readline
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-05-09 10:28:42 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-05-12 13:45:52 +0100
commita68f7e9844208ad8cd498f89b5100084ece7d0f6 (patch)
tree3c8aadccb4506ee56db78a47d0d53f43495f61c3 /readline
parenta02fcd08ddc5080696248ed7fb4bf50a24763431 (diff)
downloadbinutils-gdb-a68f7e9844208ad8cd498f89b5100084ece7d0f6.tar.gz
gdb/testsuite: extend special '^' handling to gdb_test_multiple
The commit: commit 08ec06d6440745ef9204d39197aa1e732df41056 Date: Wed Mar 29 10:41:07 2023 +0100 gdb/testsuite: special case '^' in gdb_test pattern Added some special handling of '^' to gdb_test -- a leading '^' will cause the command regexp to automatically be included in the expected output pattern. It was pointed out that the '-wrap' flag of gdb_test_multiple is supposed to work in the same way as gdb_test, and that the recent changes for '^' had not been replicated for gdb_test_multiple. This patch addresses this issue. So, after this commit, the following two constructs should have the same meaning: gdb_test "command" "^output" "test name" gdb_test_multiple "command" "test name" { -re -wrap "^output" { pass $gdb_test_name } } In both cases the '^' will case gdb.exp to inject a regexp that matches 'command' after the '^' and before the 'output', this is in addition to adding the $gdb_prompt pattern after 'output' in the normal way. The special '^' handling is only applied when '-wrap' is used, as this is the only mode that aims to mimic gdb_test. While working on this patch I realised that I could actually improve the logic for the special '^' handling in the case where the expected output pattern is empty. I replicated these updates for both gdb_test and gdb_test_multiple in order to keep these two paths in sync. There were a small number of tests that needed adjustment after this change, mostly just removing command regexps that are now added automatically, but the gdb.base/settings.exp case was a little weird as it turns out trying to match a single blank line is probably harder now than it used to be -- still, I suspect this is a pretty rare case, so I think the benefits (improved anchoring) outweigh this small downside (IMHO).
Diffstat (limited to 'readline')
0 files changed, 0 insertions, 0 deletions