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. > > Ohhh I think I see it now! > > > where `option` is the actual OptionDefinition > > And the `option` itself would know how to report / construct the error > strings?
I would like it to be that way. Let's see if it works out! 😄 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
