Files
Nils-Christian Kempke 6b7b705d7c testsuite, fortran: allow additional completions in module.exp
For ifort, ifx, and flang the tests "complete modm" and "complete
modmany" fail.  This is because all three emit additional completion
suggestions.  These additional suggestions have their origin in symbols
emitted by the compilers which can also be completed from the respective
incomplete word (modm or modmany).  For this specific example gfortran
does not emit any additional symbols.

For example, in this test the linkage name for var_a in ifx is
"modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead.
Since modmany_mp_var_a can be completed from modm and also modmany they
will get displayed, while gfortran's symbol starts with "__" and thus will
be ignored (it cannot be a completion of a word starting with "m").

Similar things happen in flang and ifort.  Some example output is shown
below:

FLANG
  (gdb) complete p modm
  p modmany
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i
  p modmany_

IFX/IFORT
  (gdb) complete p modm
  p modmany
  p modmany._
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i
  p modmany_mp_var_a_
  p modmany_mp_var_b_
  p modmany_mp_var_c_
  p modmany_mp_var_i_

GFORTRAN
  (gdb) complete p modm
  p modmany
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i

I want to emphasize: for Fortran (and also C/C++) the complete command
does not actually check whether its suggestions make sense - all it does
is look for any symbol (in the minimal symbols, partial symbols etc.)
that a given substring can be completed to (meaning that the given substring
is the beginning of the symbol).  One can easily produce a similar
output for the gfortran compiled executable.  For this look at the
slightly modified "complete p mod" in gfortran:

  (gdb) complete p mod
  p mod1
  p mod1::var_const
  ...
  p mod_1.c
  p modcounter
  p mode_t
  p modf
  ...
  p modify_ldt
  p modmany
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i
  p module
  p module.f90
  p module_entry
  p moduse
  p moduse::var_x
  p moduse::var_y

Many of the displayed symbols do not actually work with print:

  (gdb) p mode_t
  Attempt to use a type name as an expression
  (gdb) p mod_1.c
  No symbol "mod_1" in current context.
  (gdb)

I think that in the given test the output for gfortran only looks nice
"by chance" rather than is actually expected.  Expected is any output
that also contains the completions

  p modmany

  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i

while anythings else can be displayed as well (depending on the
compiler and its emitted symbols).

This, I'd consider all three outputs as valid and expected - one is just
somewhat lucky that gfortran does not produce any additional symbols that
got matched.

The given patch improves test performance for all three compilers
by allowing additional suggested completions inbetween and after
the two given blocks in the test.  I did not allow additional print
within the modmany_list block since the output is ordered alphabetically
and there should normally not appear any additional symbols there.

For flang/ifx/ifort I each see 2 failures less (which are exactly the two
complete tests).

As a side note and since I mentioned C++ in the beginning: I also tried
the gdb.cp/completion.exp.  The output seems a bit more reasonable,
mainly since C++ actually has a demangler in place and linkage symbols
do not appear in the output of complete.  Still, with a poor enough
to-be-completed string one can easily produce similar results:

  (gdb) complete p t
  ...
  p typeinfo name for void
  p typeinfo name for void const*
  p typeinfo name for void*
  p typeinfo name for wchar_t
  p typeinfo name for wchar_t const*
  p typeinfo name for wchar_t*
  p t *** List may be truncated, max-completions reached. ***
  (gdb) p typeinfo name for void*
  No symbol "typeinfo" in current context.
  (gdb) complete p B
  p BACK_SLASH
  p BUF_FIRST
  p BUF_LAST
  ...
  p Base
  p Base::Base()
  p Base::get_foo()
  p bad_key_err
  p buf
  p buffer
  p buffer_size
  p buflen
  p bufsize
  p build_charclass.isra
  (gdb) p bad_key_err
  No symbol "bad_key_err" in current context.

(compiled with gcc/g++ and breaking at main).

This patch is only about making the referenced test more 'fair' for the
other compilers.  Generally, I find the behavior of complete a bit
confusing and maybe one wants to change this at some point but this
would be a bigger task.
2022-05-31 16:44:56 +02:00

141 lines
4.6 KiB
Plaintext

# Copyright 2009-2022 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
load_lib "fortran.exp"
if {[skip_fortran_tests]} { return -1 }
standard_testfile .f90
if { [prepare_for_testing "failed to prepare" $testfile $srcfile {debug f90}] } {
return -1
}
# Test automatic language detection before the inferior starts. It tests the
# effect of expected:
# (gdb) show language
# The current source language is "auto; currently fortran".
gdb_test "p modmany::var_i" " = 14" "stopped language detection"
gdb_test "print mod1::var_const" " = 20" "fully qualified name of DW_TAG_constant"
# Avoid shared lib symbols.
gdb_test_no_output "set auto-solib-add off"
if ![fortran_runto_main] then {
perror "couldn't run to main"
return
}
# Avoid libc symbols.
gdb_test "nosharedlibrary"
set int_type [fortran_int4]
# Test 'info variables' can find module variables.
set mod_re \
[multi_line \
"18:\[ \t\]+${int_type} mod1::var_const;" \
"17:\[ \t\]+${int_type} mod1::var_i;" \
"23:\[ \t\]+${int_type} mod2::var_i;" \
"28:\[ \t\]+${int_type} mod3::mod1;" \
"27:\[ \t\]+${int_type} mod3::mod2;" \
"29:\[ \t\]+${int_type} mod3::var_i;" \
"33:\[ \t\]+${int_type} modmany::var_a;" \
"33:\[ \t\]+${int_type} modmany::var_b;" \
"33:\[ \t\]+${int_type} modmany::var_c;" \
"33:\[ \t\]+${int_type} modmany::var_i;" \
"37:\[ \t\]+${int_type} moduse::var_x;" \
"37:\[ \t\]+${int_type} moduse::var_y;"]
set state 0
gdb_test_multiple "info variables -n" "" {
-re "\r\nAll defined variables:" {
if { $state == 0 } { set state 1 }
exp_continue
}
-re "\r\n\r\nFile .*[string_to_regexp $srcfile]:" {
if { $state == 1 } { set state 2 }
exp_continue
}
-re $mod_re {
if { $state == 2 } { set state 3 }
exp_continue
}
-re "\r\n\r\nFile \[^\r\n\]*:" {
exp_continue
}
-re -wrap "" {
if { $state == 3} {
pass $gdb_test_name
} else {
fail $gdb_test_name
}
}
}
# Do not use simple single-letter names as GDB would pick up for expectedly
# nonexisting symbols some static variables from system libraries debuginfos.
gdb_breakpoint [gdb_get_line_number "i-is-1"]
gdb_continue_to_breakpoint "i-is-1" ".*i-is-1.*"
gdb_test "print var_i" " = 1" "print var_i value 1"
gdb_breakpoint [gdb_get_line_number "i-is-2"]
gdb_continue_to_breakpoint "i-is-2" ".*i-is-2.*"
gdb_test "print var_i" " = 2" "print var_i value 2"
gdb_breakpoint [gdb_get_line_number "i-is-3"]
gdb_continue_to_breakpoint "i-is-3" ".*i-is-3.*"
# Ensure that the scope is correctly resolved.
gdb_test "p mod3" "Attempt to use a type name as an expression" "print mod3"
gdb_test "p mod2" " = 3" "print mod2"
gdb_test "p mod1" " = 3" "print mod1"
gdb_breakpoint [gdb_get_line_number "a-b-c-d"]
gdb_continue_to_breakpoint "a-b-c-d" ".*a-b-c-d.*"
gdb_test "print var_a" "No symbol \"var_a\" in current context\\."
gdb_test "print var_b" " = 11"
gdb_test "print var_c" "No symbol \"var_c\" in current context\\."
gdb_test "print var_d" " = 12"
gdb_test "print var_i" " = 14" "print var_i value 14"
gdb_test "print var_x" " = 30" "print var_x value 30"
gdb_test "print var_y" "No symbol \"var_y\" in current context\\."
gdb_test "print var_z" " = 31" "print var_x value 31"
gdb_test "ptype modmany" "type = module modmany"
proc complete {expr list} {
set n_lines "\(?:\\r\\n.*\)*"
set cmd "complete p $expr"
set expect [join [concat [list $cmd] $list] $n_lines]
gdb_test $cmd "$expect$n_lines" "complete $expr"
}
set modmany_list {modmany::var_a modmany::var_b modmany::var_c modmany::var_i}
complete "modm" "modmany $modmany_list"
complete "modmany" "modmany $modmany_list"
complete "modmany::" $modmany_list
complete "modmany::var" $modmany_list
# Breakpoint would work in language "c".
gdb_test "show language" {The current source language is "(auto; currently )?fortran".}
# gcc-4.4.2: The main program is always $fmain in .symtab so "runto" above
# works. But DWARF DW_TAG_subprogram contains the name specified by
# the "program" Fortran statement.
if [gdb_breakpoint "module"] {
pass "setting breakpoint at module"
}