[Bug cli/15104] New: deprecated_cmd_warning does not work for prefixed commands

[Bug cli/15104] New: deprecated_cmd_warning does not work for prefixed commands

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15104

             Bug #: 15104
           Summary: deprecated_cmd_warning does not work for prefixed
                    commands
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: minor
          Priority: P2
         Component: cli
        AssignedTo: unassigned@sourceware.org
        ReportedBy: jan.kratochvil@redhat.com
    Classification: Unclassified


When one calls deprecate_cmd for a command with prefix (=which was added to a
different list than &cmdlist) it never triggers.

deprecated_cmd_warning gets called only with the last part of the command, such
as for deprecated "target record" *text is just " record".

Moreover cmd_list_element->prefix is never set as GDB currently calls
add_prefix_cmd before adding its children but it was meant to be called
afterwards - only add_prefix_cmd sets the PREFIX field of children.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug cli/15104] deprecated_cmd_warning does not work for prefixed commands

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15104

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9ef6d4a1b48ea1f5693aa270b8b768146a31b9e9

commit 9ef6d4a1b48ea1f5693aa270b8b768146a31b9e9
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Thu Dec 10 13:19:40 2020 +0000

    gdb: give deprecated command warning for aliases with a prefix

    I noticed that deprecated aliases that have a prefix don't give a
    deprecated command warning.  For example looking in mi/mi-main.c we
    see this:

      c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &setlist);
      deprecate_cmd (c, "set mi-async");
      c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &showlist);
      deprecate_cmd (c, "show mi-async");

    So both 'set target-async' and 'show target-async' are deprecated and
    should be giving a warning, however, in use we see no warning given.

    This is a consequence of how the code that should give this
    warning (deprecated_cmd_warning) performs a second command lookup in
    order to distinguish between aliases and real commands, and that the
    code that calls this (lookup_cmd_1) strips off prefix commands as it
    calls itself recursively.

    As a result when we are considering an alias like 'set target-async'
    we first enter lookup_cmd_1 with text = "set target-async", we spot
    the 'set' command prefix and then recursively call lookup_cmd_1 with
    text = "target-async".

    We spot that 'target-async' is a known alias but that it is
    deprecated, and so call deprecated_cmd_warning passing in the value of
    text, which remember is now "target-async".

    In deprecated_cmd_warning we again perform a command lookup starting
    from the top-level cmdlist, but now we're trying to find just
    "target-async", this fails (as this command requires the 'set' prefix,
    and so no warning is given.

    I resolved this issue by passing a command list to the function
    deprecated_cmd_warning, this is the list in which the command can be
    found.

    A new test is added to cover this case.

    However, there is an additional problem which will be addressed in a
    subsequent patch.

    Consider this GDB session:

      (gdb) define set xxx_yyy
      Type commands for definition of "set xxx_yyy".
      End with a line saying just "end".
      >echo in set xxx_yyy command\n
      >end
      (gdb) alias set qqq_aaa=set xxx_yyy
      (gdb) maintenance deprecate set qqq_aaa
      (gdb) set qqq_aaa
      Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
      No alternative known.

      in set xxx_yyy command
      (gdb)

    Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
    to be wrong.  I think the proper warning should read:

      (gdb) set qqq_aaa
      Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy' is
deprecated.
      No alternative known.

    With the 'set' prefixes added.  A later patch will resolve this
    issue.

    gdb/ChangeLog:

            PR cli/15104
            * cli/cli-decode.c (lookup_cmd_1): Pass command list to
            deprecated_cmd_warning.
            (deprecated_cmd_warning): Take extra parameter, call
            lookup_cmd_composition_1 and pass new parameter through.
            (lookup_cmd_composition_1): New function, takes implementation of
            lookup_cmd_composition but with extra parameter.
            (lookup_cmd_composition): Now calls lookup_cmd_composition_1
            passing in cmdlist.
            * command.h (deprecated_cmd_warning): Add extra parameter to
            declaration.
            * top.c (execute_command): Pass cmdlist to deprecated_cmd_warning.

    gdb/testsuite/ChangeLog:

            PR cli/15104
            * gdb.base/commands.exp: Add additional tests.
            * gdb.base/completion.exp: Add additional tests.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/15104] deprecated_cmd_warning does not work for prefixed commands

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15104

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |tromey at sourceware dot org
   Target Milestone|---                         |11.1

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
I think this is fixed now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.