[all-commits] [llvm/llvm-project] 7e1432: [lldb] Standardize command option parsing error me...

[Alex Langford via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7e1432f1258e229a4fcc9c017937166f0578e1f8
      https://github.com/llvm/llvm-project/commit/7e1432f1258e229a4fcc9c017937166f0578e1f8
  Author: Alex Langford <alangford at apple.com>
  Date:   2024-02-21 (Wed, 21 Feb 2024)

  Changed paths:
    M lldb/include/lldb/Interpreter/Options.h
    M lldb/source/Commands/CommandObjectBreakpoint.cpp
    M lldb/source/Interpreter/Options.cpp
    M lldb/unittests/Interpreter/CMakeLists.txt
    A lldb/unittests/Interpreter/TestOptions.cpp

  Log Message:
  -----------
  [lldb] Standardize command option parsing error messages (#82273)

I have been looking to simplify parsing logic and improve the interfaces
so that they are both easier to use and harder to abuse. To be specific,
I am referring to functions such as `OptionArgParser::ToBoolean`: I
would like to go from its current interface to something more like
`llvm::Error<bool> ToBoolean(llvm::StringRef option_arg)`.

Through working on that, I encountered 2 inconveniences:
1. Option parsing code is not uniform. Every function writes a slightly
different error message, so incorporating an error message from the
`ToBoolean` implementation is going to be laborious as I figure out what
exactly needs to change or stay the same.
2. Changing the interface of `ToBoolean` would require a global atomic
change across all of the Command code. This would be quite frustrating
to do because of the non-uniformity of our existing code.

To address these frustrations, I think it would be easiest to first
standardize the error reporting mechanism when parsing options in
commands. I do so by introducing `CreateOptionParsingError` which will
create an error message of the shape:
Invalid value ('${option_arg}') for -${short_value} ('${long_value}'):
${additional_context}

Concretely, it would look something like this:
(lldb) breakpoint set -n main -G yay
error: Invalid value ('yay') for -G (auto-continue): Failed to parse as
boolean

After this, updating the interfaces for parsing the values themselves
should become simpler. Because this can be adopted incrementally, this
should be able to done over the course of time instead of all at once as
a giant difficult-to-review change. I've changed exactly one function
where this function would be used as an illustration of what I am
proposing.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications