)]}'
{
  "commit": "6b7b705d7c21b0d0dd9eaf5273a711e20e238ec3",
  "tree": "44c5f3ac1fd2243e2d58eac16ba30623e6f2ce52",
  "parents": [
    "b8dd7ddff9b71ae2c301957af546724f948a467e"
  ],
  "author": {
    "name": "Nils-Christian Kempke",
    "email": "nils-christian.kempke@intel.com",
    "time": "Tue May 31 16:43:45 2022 +0200"
  },
  "committer": {
    "name": "Nils-Christian Kempke",
    "email": "nils-christian.kempke@intel.com",
    "time": "Tue May 31 16:44:56 2022 +0200"
  },
  "message": "testsuite, fortran: allow additional completions in module.exp\n\nFor ifort, ifx, and flang the tests \"complete modm\" and \"complete\nmodmany\" fail.  This is because all three emit additional completion\nsuggestions.  These additional suggestions have their origin in symbols\nemitted by the compilers which can also be completed from the respective\nincomplete word (modm or modmany).  For this specific example gfortran\ndoes not emit any additional symbols.\n\nFor example, in this test the linkage name for var_a in ifx is\n\"modmany_mp_var_a_\" while gfortran uses \"__modmany_MOD_var_a\" instead.\nSince modmany_mp_var_a can be completed from modm and also modmany they\nwill get displayed, while gfortran\u0027s symbol starts with \"__\" and thus will\nbe ignored (it cannot be a completion of a word starting with \"m\").\n\nSimilar things happen in flang and ifort.  Some example output is shown\nbelow:\n\nFLANG\n  (gdb) complete p modm\n  p modmany\n  p modmany::var_a\n  p modmany::var_b\n  p modmany::var_c\n  p modmany::var_i\n  p modmany_\n\nIFX/IFORT\n  (gdb) complete p modm\n  p modmany\n  p modmany._\n  p modmany::var_a\n  p modmany::var_b\n  p modmany::var_c\n  p modmany::var_i\n  p modmany_mp_var_a_\n  p modmany_mp_var_b_\n  p modmany_mp_var_c_\n  p modmany_mp_var_i_\n\nGFORTRAN\n  (gdb) complete p modm\n  p modmany\n  p modmany::var_a\n  p modmany::var_b\n  p modmany::var_c\n  p modmany::var_i\n\nI want to emphasize: for Fortran (and also C/C++) the complete command\ndoes not actually check whether its suggestions make sense - all it does\nis look for any symbol (in the minimal symbols, partial symbols etc.)\nthat a given substring can be completed to (meaning that the given substring\nis the beginning of the symbol).  One can easily produce a similar\noutput for the gfortran compiled executable.  For this look at the\nslightly modified \"complete p mod\" in gfortran:\n\n  (gdb) complete p mod\n  p mod1\n  p mod1::var_const\n  ...\n  p mod_1.c\n  p modcounter\n  p mode_t\n  p modf\n  ...\n  p modify_ldt\n  p modmany\n  p modmany::var_a\n  p modmany::var_b\n  p modmany::var_c\n  p modmany::var_i\n  p module\n  p module.f90\n  p module_entry\n  p moduse\n  p moduse::var_x\n  p moduse::var_y\n\nMany of the displayed symbols do not actually work with print:\n\n  (gdb) p mode_t\n  Attempt to use a type name as an expression\n  (gdb) p mod_1.c\n  No symbol \"mod_1\" in current context.\n  (gdb)\n\nI think that in the given test the output for gfortran only looks nice\n\"by chance\" rather than is actually expected.  Expected is any output\nthat also contains the completions\n\n  p modmany\n\n  p modmany::var_a\n  p modmany::var_b\n  p modmany::var_c\n  p modmany::var_i\n\nwhile anythings else can be displayed as well (depending on the\ncompiler and its emitted symbols).\n\nThis, I\u0027d consider all three outputs as valid and expected - one is just\nsomewhat lucky that gfortran does not produce any additional symbols that\ngot matched.\n\nThe given patch improves test performance for all three compilers\nby allowing additional suggested completions inbetween and after\nthe two given blocks in the test.  I did not allow additional print\nwithin the modmany_list block since the output is ordered alphabetically\nand there should normally not appear any additional symbols there.\n\nFor flang/ifx/ifort I each see 2 failures less (which are exactly the two\ncomplete tests).\n\nAs a side note and since I mentioned C++ in the beginning: I also tried\nthe gdb.cp/completion.exp.  The output seems a bit more reasonable,\nmainly since C++ actually has a demangler in place and linkage symbols\ndo not appear in the output of complete.  Still, with a poor enough\nto-be-completed string one can easily produce similar results:\n\n  (gdb) complete p t\n  ...\n  p typeinfo name for void\n  p typeinfo name for void const*\n  p typeinfo name for void*\n  p typeinfo name for wchar_t\n  p typeinfo name for wchar_t const*\n  p typeinfo name for wchar_t*\n  p t *** List may be truncated, max-completions reached. ***\n  (gdb) p typeinfo name for void*\n  No symbol \"typeinfo\" in current context.\n  (gdb) complete p B\n  p BACK_SLASH\n  p BUF_FIRST\n  p BUF_LAST\n  ...\n  p Base\n  p Base::Base()\n  p Base::get_foo()\n  p bad_key_err\n  p buf\n  p buffer\n  p buffer_size\n  p buflen\n  p bufsize\n  p build_charclass.isra\n  (gdb) p bad_key_err\n  No symbol \"bad_key_err\" in current context.\n\n(compiled with gcc/g++ and breaking at main).\n\nThis patch is only about making the referenced test more \u0027fair\u0027 for the\nother compilers.  Generally, I find the behavior of complete a bit\nconfusing and maybe one wants to change this at some point but this\nwould be a bigger task.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "08dc1a50e88078339f01a1084d0bbfe845d2a368",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.fortran/module.exp",
      "new_id": "fe539fbc6d347863ee34a7afc0c780a87f5c5503",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.fortran/module.exp"
    }
  ]
}