bulbazord wrote: > This LGTM! > > I don't think I can see far enough ahead on what you are planning here, but I > was just wondering if the ultimate goal is to have the `option_arg.getAsT` > return an `Expected<T>`. In this case, wouldn't all these arguments (short > option, long option, additional context) have to be part of the interface of > `getAsT`? I suspect this is not your goal, but I can't see a way around that
The ultimate goal is to have option parsing be much more streamlined and automated. The majority of option parsing is just taking some primitive value and trying to grab its value from a string. There are places where we need additional context (e.g. in this PR, there's a place where we want to select a thread ID so there's more validation needed). I want to be able to write those pretty naturally too. The first step in my plan is to centralize how we create error messages. The majority of parsing errors will be "I couldn't turn this into a boolean/integer/address/other", so I'm going to create something that is better than what we have today. The step after that will be to revamp the parsing step. Ideally instead of writing `OptionArgParser::ToBoolean` the way we do today, there will be something like `llvm::Expected<bool> value_or_error = ParseAsBool(option);` where `option` is the actual OptionDefinition. I'm not tied to these abstractions, but I am committed to the path of making this easier to write and maintain. https://github.com/llvm/llvm-project/pull/82273 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
