Lancelot SIX
86a8399998
There is a expect support library in the source tree designed to help
developers test the auto-completion capabilities of GDB.
One of the functions is test_gdb_complete_unique_re. It is used
(usually indirectly via test_gdb_complete_unique) to test that a given
input line is completed as a given output line. The test checks for two
ways to do the completion: using tab-completion, or using the
'complete' command. To do this, calls to two dedicated functions are
performed. If we omit few details, we can consider that a call to
test_gdb_complete_unique $input $expected
is equivalent to the two following calls:
test_gdb_complete_tab_unique $input $expected
test_gdb_complete_cmd_unique $input $expected
When using the tab-completion, everything works as expected, but some
care must be taken when using the 'complete' command if the given input
has leading whitespaces. In such situation, the output of the
'complete' command will drop the leading whitespaces.
The current approach is that in such situation, the input and expected
outputs are right trimmed (i.e. all leading whitespaces are removed)
when performing the command completion check.
This means that the following call:
test_gdb_complete_unique " $input" " $expected"
is almost equivalent to (again, omitting few details and arguments):
test_gdb_complete_tab_unique " $input" " $expected"
test_gdb_complete_cmd_unique "$input" "$expected"
This approach comes with a problem that we encounter when running the
tests in complete-empty.exp. When doing so, we have:
Running .../gdb/testsuite/gdb.base/complete-empty.exp ...
DUPLICATE: gdb.base/complete-empty.exp: empty-input-line: cmd complete ""
This is because the test file does something like:
test_gdb_complete_unique "" "!" " " 1
test_gdb_complete_unique " " " !" " " 1¬
which, if we do the substitution introduced above is equivalent to:
test_gdb_complete_tab_unique "" "!"
test_gdb_complete_cmd_unique "" "!"
test_gdb_complete_tab_unique " " " !"
test_gdb_complete_cmd_unique "" "!"
We see that the lines 2 and 4 are now the same, and for this reason the
testing framework complains about DUPLICATE test names.
To fix that, this commit proposes that instead of left trimming both
input and expected outputs, only the expected output is trimmed.
Care must be taken in the case the completion gives more possibilities
than allowed by the max-completions setting. In this case, the input
will be repeated in the output in its left trimmed version. This commit
also ensures that this is taken care of.
With this commit, the gdb.base/complete-empty.exp still passes all its
tests but does not report the DUPLICATE anymore.
Tested on x86_64-linux.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.