[all-commits] [llvm/llvm-project] 2a6dbe: [lldb] Fix (unintentional) recursion in CommandObj...

[Jonas Devlieghere via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2a6dbedf5a923512ba8b5c2d192b5fc8bb1210fd
      https://github.com/llvm/llvm-project/commit/2a6dbedf5a923512ba8b5c2d192b5fc8bb1210fd
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   2022-02-23 (Wed, 23 Feb 2022)

  Changed paths:
    M lldb/include/lldb/Interpreter/CommandReturnObject.h
    M lldb/source/Commands/CommandObjectRegexCommand.cpp
    M lldb/source/Commands/CommandObjectRegexCommand.h
    M lldb/source/Interpreter/CommandReturnObject.cpp
    M lldb/unittests/Interpreter/CMakeLists.txt
    A lldb/unittests/Interpreter/TestRegexCommand.cpp

  Log Message:
  -----------
  [lldb] Fix (unintentional) recursion in CommandObjectRegexCommand

Jim noticed that the regex command is unintentionally recursive. Let's
use the following command regex as an example:

  (lldb) com regex humm 's/([^ ]+) ([^ ]+)/p %1 %2 %1 %2/'

If we call it with arguments foo bar, thing behave as expected:

  (lldb) humm foo bar
  (...)
  foo bar foo bar

However, if we include %2 in the arguments, things break down:

  (lldb) humm fo%2o bar
  (...)
  fobaro bar fobaro bar

The problem is that the implementation of the substitution is too naive.
It substitutes the %1 token into the target template in place, then does
the %2 substitution starting with the resultant string. So if the
previous substitution introduced a %2 token, it would get processed in
the second sweep, etc.

This patch addresses the issue by walking the command once and
substituting the % variables in place.

  (lldb) humm fo%2o bar
  (...)
  fo%2o bar fo%2o bar

Furthermore, this patch also reports an error if not enough variables
were provided and add support for substituting %0.

rdar://81236994

Differential revision: https://reviews.llvm.org/D120101