From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17078 invoked by alias); 13 Dec 2017 13:26:43 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 17043 invoked by uid 89); 13 Dec 2017 13:26:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Dec 2017 13:26:41 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9A57F80477 for ; Wed, 13 Dec 2017 13:26:40 +0000 (UTC) Received: from cascais.lan (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 284C2614FF for ; Wed, 13 Dec 2017 13:26:39 +0000 (UTC) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 3/3] Tighten regexp of lib/completion-support.exp:test_gdb_complete_tab_multiple Date: Wed, 13 Dec 2017 13:26:00 -0000 Message-Id: <1513171596-10665-4-git-send-email-palves@redhat.com> In-Reply-To: <1513171596-10665-1-git-send-email-palves@redhat.com> References: <1513171596-10665-1-git-send-email-palves@redhat.com> X-SW-Source: 2017-12/txt/msg00304.txt.bz2 While writing the tests included in the previous commit, I noticed that test_gdb_complete_tab_multiple would not FAIL if GDB happens to show more completions than expected before the expected list. E.g., with something like this, expecting "p foo" to complete to "foo2" and "foo3": test_gdb_complete_tab_multiple "p foo" "" { "foo2" "foo3" } and then if foo actually completes to: (gdb) p foo[TAB] foo1 foo2 foo3 ^^^^ we'd still PASS. (Note the spurious "foo1" above.) This tightens the regexp with a beginning anchor thus making the completions above cause a FAIL. Other similar functions in completion-support.exp already do something like this; I had just missed this one originally. Thankfully, this did not expose any problems in the gdb.linespec/ tests. Phew. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves * lib/completion-support.exp (test_gdb_complete_tab_multiple): Tighten regexp by matching with an anchor. --- gdb/testsuite/lib/completion-support.exp | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/lib/completion-support.exp b/gdb/testsuite/lib/completion-support.exp index fe5b16a..bebf90e 100644 --- a/gdb/testsuite/lib/completion-support.exp +++ b/gdb/testsuite/lib/completion-support.exp @@ -139,9 +139,12 @@ proc test_gdb_complete_tab_multiple { input_line add_completed_line \ # extra tab to show the matches list. if {$add_completed_line != ""} { send_gdb "\t" + set maybe_bell ${completion::bell_re} + } else { + set maybe_bell "" } gdb_test_multiple "" "$test (second tab)" { - -re "$expected_re\r\n$gdb_prompt $input_line_re$add_completed_line_re$" { + -re "^${maybe_bell}\r\n$expected_re\r\n$gdb_prompt $input_line_re$add_completed_line_re$" { pass "$test" } } -- 2.5.5