Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Keith Seitz <keiths@redhat.com>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>,
	       "gdb-patches@sourceware.org ml"
	<gdb-patches@sourceware.org>
Subject: Re: [RFA] completer test [was Re: [RFC] Cleanup for make_source_files_completion_list]
Date: Thu, 16 May 2013 09:19:00 -0000	[thread overview]
Message-ID: <5194A48D.4060806@redhat.com> (raw)
In-Reply-To: <51941E85.8010104@redhat.com>

On 05/16/2013 12:47 AM, Keith Seitz wrote:
> On 05/15/2013 03:33 PM, Sergio Durigan Junior wrote:
>> Wouldn't it be better to use the "complete" command?  Here is what I see
>> when I use it:
>>
>>      (gdb) complete break filesy
>>      break filesym
>>      break filesym.c
> 
> Is that necessarily "better" than testing what a user would actually type? I don't know. gdb.base/completion.exp uses both forms.

Yeah.  Testing just "complete" doesn't cover everything
necessary.  See thread around:

 http://sourceware.org/ml/gdb-patches/2011-05/msg00032.html

"complete" is useful for frontends, so it's good to test it too.

An idea would be to have a mechanism (procedure, whatever) in (or used by)
completion.exp that given an input string and the expected completions
exercises both "complete" and "\t" with a single call.  E.g.,:

test_completion "break filesy" { "break" "break filesym.c" }

Probably, the completion.exp tests already test the specifics of gdb<->readline
interaction that only the \t code paths trigger, independent of specific
completer, so for testing specific completers it's probably fine to just
go with using the simpler "complete" way only.  If we had the mechanism
suggested above, then we wouldn't have to think about considering whether
all bases are covered though.  We'd just always use it.  :-)

This patch seems to involve testing sort of actual completion mechanics,
so it looks like a specific case where testing (at least) the \t variant
is good.

> This is the first I've heard of send_gdb being deprecated. As far as I can tell, there is no other way to directly test completion this way. I do see, though, that completion.exp uses gdb_test_multiple instead of gdb_expect... If it truly is deprecated, I would expect send_gdb to be made "private" in some way. [deprecated_send_gdb?] Or at least mentioned in lib/gdb.exp.

Yeah.  Testing completion is one of the cases that need to use it.
If we had a higher level mechanism/procedure that simplified \t completion
testing, we could hide those send_gdb calls though.  :-)

> If there is a preference for one or the other [or an actual policy], I will certainly make necessary changes.
> 
> I'm using a similar test strategy for my explicit completion tests, which I am about to submit...

Please use gdb_test_multiple.  See e.g., how completion.exp itself
simplified much when converted to it:

 http://sourceware.org/ml/gdb-patches/2011-05/msg00063.html

-- 
Pedro Alves


  parent reply	other threads:[~2013-05-16  9:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07 19:46 [RFC] Cleanup for make_source_files_completion_list Keith Seitz
2013-05-09 20:58 ` Tom Tromey
2013-05-09 23:45 ` Doug Evans
2013-05-13 18:42   ` Keith Seitz
2013-05-13 21:11     ` Keith Seitz
2013-05-15 17:36       ` Keith Seitz
2013-05-15 19:32         ` [RFA] completer test [was Re: [RFC] Cleanup for make_source_files_completion_list] Keith Seitz
2013-05-15 20:01           ` Tom Tromey
2013-05-15 21:22             ` Keith Seitz
2013-05-15 22:33           ` Sergio Durigan Junior
2013-05-15 23:47             ` Keith Seitz
2013-05-16  0:21               ` Sergio Durigan Junior
2013-05-16  0:27               ` Stan Shebs
2013-05-16  9:38                 ` Pedro Alves
2013-05-16  5:30               ` Joel Brobecker
2013-05-16  5:49                 ` Joel Brobecker
2013-05-16 15:41                   ` Keith Seitz
2013-05-17  5:14                     ` Joel Brobecker
2013-05-17 16:27                       ` Tom Tromey
2013-05-20  5:28                         ` Joel Brobecker
2013-05-20 14:47                           ` Tom Tromey
2013-05-21  5:43                             ` Checked in: " Joel Brobecker
2013-05-21  5:44                               ` Joel Brobecker
2013-05-16  5:53                 ` Sergio Durigan Junior
2013-05-16  6:00                   ` Joel Brobecker
2013-05-16  9:19               ` Pedro Alves [this message]
2013-05-16  9:26                 ` Joel Brobecker
2013-05-16 10:18                   ` Pedro Alves

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=5194A48D.4060806@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=sergiodj@redhat.com \
    /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