Lib option definitely does, as its entire purpose is to be powerful and flexible enough to mimic arbitrary command line tools.  <br><br>cl::opt is a little less powerful but it still preserves order among multiple options with the same flag, just not multiple options with different flags.  <br><br>I don’t have a strong opinion that this particular change should be gated on that, it’s just nice when we can reuse llvm logic.  Sometimes it fixes latent bugs, sometimes it enables new functionality that wasn’t possible before, etc.  up to you if you wanna give it a shot<br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 18, 2018 at 7:39 PM Jonas Devlieghere via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">JDevlieghere added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D54682#1302436" rel="noreferrer" target="_blank">https://reviews.llvm.org/D54682#1302436</a>, @zturner wrote:<br>
<br>
> I’ve often thought we should convert LLDB’s command line parsing code over<br>
>  to use either cl::opt or lib/Option. This would also solve the problem you<br>
>  describe here at the same time.<br>
><br>
> Do you think it’s worth trying to do this?<br>
<br>
<br>
I believe both would have the issue that options are not processed in the order specified. I guess it depends on whether people care about this? Happy to give that a shot if the consensus is "nobody cares" :-)<br>
<br>
<br>
Repository:<br>
  rLLDB LLDB<br>
<br>
<a href="https://reviews.llvm.org/D54682" rel="noreferrer" target="_blank">https://reviews.llvm.org/D54682</a><br>
<br>
<br>
<br>
</blockquote></div>