llvm dev - Apr 2019 - Accept --long-option but not -long-option for llvm binary utilities

It's actually a bit weirder than you might think.  The CommandLine parser
will happily eat as many dashes as you care to write, e.g., `----sections`
is the same as `-sections`.


On Tue, Apr 16, 2019 at 2:11 AM James Henderson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> As I think I said elsewhere, I find it weird that LLVM tools accept long
> arguments with a single dash, and I'd be happy for the binary utilities
at
> least to move away from this approach, if it improves compatibility/reduces
> gotchas etc. One of the points from the BoF on the LLVM binutils at the
> recent Euro LLVM developers' meeting was that if we are going to break
> compatibility with previous versions of LLVM, we're better off doing it
> now, rather than leaving it a long time. The longer it gets left, the more
> users, and therefore the more likely somebody has come to rely on it in a
> non-trivial-to-fix way.
>
> If we are particularly concerned with llvm-readobj, we could (if it is
> practical) try handling it differently to llvm-readelf. An approach as
> suggested by Michael Spencer at the BoF could be to migrate away from using
> cl::opt and follow the same route as llvm-objcopy. That would allow us to
> have different option sets for the two versions of that tool, if we wanted.
>
> On Tue, 16 Apr 2019 at 08:44, Jordan Rupprecht <rupprecht at
google.com>
> wrote:
>
>> For binutil compatibility, and in general for any new tools, this
sounds
>> reasonable to me. But I'd worry that things like llvm-readobj have
existed
>> for a long time and people are used to flags like
"-sections", and it may
>> be complicated to change that now. (I guess this RFC is a check to see
if
>> this is true for anyone on the mailing list).
>>
>> What happens if you make this change and someone does use
"-sections" --
>> will the command line parser suggest "--sections", or will it
just fail
>> because one of -s, -e, -c, etc. is not a valid option?
>>
>> On Tue, Apr 16, 2019 at 9:00 AM Rui Ueyama via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> That change makes sense to me. I'd like to note that the policy
should
>>> be set per-command basis, as some commands are required to accept
both `--`
>>> and `-` for long option names. lld is such command.
>>>
>>> On Tue, Apr 16, 2019 at 3:41 PM Fāng-ruì Sòng via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Many llvm utilities use cl::ParseCommandLineOptions()
>>>> (include/Support/CommandLine.h) to parse command line options.
The cl
>>>> library accepts both -long-option and --long-option forms, with
the single
>>>> dash form (-long-option) being more popular.
>>>>
>>>> We also have many binary utilities (llvm-objcopy llvm-objdump
>>>> llvm-readobj llvm-size ...) whose names reflect what they
imitate. For
>>>> compatibility with GNU binutils (and some Unix utilities
transitively),
>>>> these utilities accept many short options. People who use llvm
utilities as
>>>> replacement of GNU binutils may use the grouped option syntax
(POSIX
>>>> Utility Conventions), e.g. -Sx => -S -x, -Wd => -W -d,
-sj.text => -s
>>>> -j.text
>>>>
>>>> The problem is, grouped short options don't play well with
>>>> -long-option. Sometimes there can be ambiguity. The issue is
more prominent
>>>> if the short option accepts an argument.
>>>>
>>>> An approach to prevent the ambiguity is to just disallow
-long-option.
>>>> In D60439, I plan to make llvm-objcopy accept --long-option but
not
>>>> -long-option.
>>>> It will make its command line option parsing behave more like
GNU
>>>> objcopy and less like a regular llvm utility. What do people
think of the
>>>> divergence?
>>>>
>>>> Further, can we make similar changes to other llvm binary
utilities
>>>> (their names give people the expectation), especially those
with many short
>>>> options such as llvm-objdump and llvm-readobj? llvm-readobj
behaves like
>>>> GNU readelf if you name it "llvm-readelf". (I
don't suggest disallowing
>>>> -long-option for utilities other than binutils)
>>>>
>>>> (Note, llvm-objcopy is a new member of the family and it uses
tablegen
>>>> based include/llvm/Option/Opton.h, instead of cl:: as other
utilities do.)
>>>>
>>>>
>>>>
>>>> --
>>>> 宋方睿
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190416/98ff0763/attachment.html>

On Wed, Apr 17, 2019 at 10:42 AM Don Hinton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> It's actually a bit weirder than you might think.  The CommandLine
parser
> will happily eat as many dashes as you care to write, e.g., `----sections`
> is the same as `-sections`.
>
That seems true, and I'm a bit surprised. Accepting three or more dashes is
definitely a bug.

On Tue, Apr 16, 2019 at 2:11 AM James Henderson via llvm-dev
<
> llvm-dev at lists.llvm.org> wrote:
>
>> As I think I said elsewhere, I find it weird that LLVM tools accept
long
>> arguments with a single dash, and I'd be happy for the binary
utilities at
>> least to move away from this approach, if it improves
compatibility/reduces
>> gotchas etc. One of the points from the BoF on the LLVM binutils at the
>> recent Euro LLVM developers' meeting was that if we are going to
break
>> compatibility with previous versions of LLVM, we're better off
doing it
>> now, rather than leaving it a long time. The longer it gets left, the
more
>> users, and therefore the more likely somebody has come to rely on it in
a
>> non-trivial-to-fix way.
>>
>> If we are particularly concerned with llvm-readobj, we could (if it is
>> practical) try handling it differently to llvm-readelf. An approach as
>> suggested by Michael Spencer at the BoF could be to migrate away from
using
>> cl::opt and follow the same route as llvm-objcopy. That would allow us
to
>> have different option sets for the two versions of that tool, if we
wanted.
>>
>> On Tue, 16 Apr 2019 at 08:44, Jordan Rupprecht <rupprecht at
google.com>
>> wrote:
>>
>>> For binutil compatibility, and in general for any new tools, this
sounds
>>> reasonable to me. But I'd worry that things like llvm-readobj
have existed
>>> for a long time and people are used to flags like
"-sections", and it may
>>> be complicated to change that now. (I guess this RFC is a check to
see if
>>> this is true for anyone on the mailing list).
>>>
>>> What happens if you make this change and someone does use
"-sections" --
>>> will the command line parser suggest "--sections", or
will it just fail
>>> because one of -s, -e, -c, etc. is not a valid option?
>>>
>>> On Tue, Apr 16, 2019 at 9:00 AM Rui Ueyama via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> That change makes sense to me. I'd like to note that the
policy should
>>>> be set per-command basis, as some commands are required to
accept both `--`
>>>> and `-` for long option names. lld is such command.
>>>>
>>>> On Tue, Apr 16, 2019 at 3:41 PM Fāng-ruì Sòng via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Many llvm utilities use cl::ParseCommandLineOptions()
>>>>> (include/Support/CommandLine.h) to parse command line
options. The cl
>>>>> library accepts both -long-option and --long-option forms,
with the single
>>>>> dash form (-long-option) being more popular.
>>>>>
>>>>> We also have many binary utilities (llvm-objcopy
llvm-objdump
>>>>> llvm-readobj llvm-size ...) whose names reflect what they
imitate. For
>>>>> compatibility with GNU binutils (and some Unix utilities
transitively),
>>>>> these utilities accept many short options. People who use
llvm utilities as
>>>>> replacement of GNU binutils may use the grouped option
syntax (POSIX
>>>>> Utility Conventions), e.g. -Sx => -S -x, -Wd => -W
-d, -sj.text => -s
>>>>> -j.text
>>>>>
>>>>> The problem is, grouped short options don't play well
with
>>>>> -long-option. Sometimes there can be ambiguity. The issue
is more prominent
>>>>> if the short option accepts an argument.
>>>>>
>>>>> An approach to prevent the ambiguity is to just disallow
-long-option.
>>>>> In D60439, I plan to make llvm-objcopy accept --long-option
but not
>>>>> -long-option.
>>>>> It will make its command line option parsing behave more
like GNU
>>>>> objcopy and less like a regular llvm utility. What do
people think of the
>>>>> divergence?
>>>>>
>>>>> Further, can we make similar changes to other llvm binary
utilities
>>>>> (their names give people the expectation), especially those
with many short
>>>>> options such as llvm-objdump and llvm-readobj? llvm-readobj
behaves like
>>>>> GNU readelf if you name it "llvm-readelf". (I
don't suggest disallowing
>>>>> -long-option for utilities other than binutils)
>>>>>
>>>>> (Note, llvm-objcopy is a new member of the family and it
uses tablegen
>>>>> based include/llvm/Option/Opton.h, instead of cl:: as other
utilities do.)
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 宋方睿
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/0eb207ab/attachment.html>

It does this in a few places:

      // Eat leading dashes.
      while (!ArgName.empty() && ArgName[0] == '-')
        ArgName = ArgName.substr(1);


On Tue, Apr 16, 2019 at 6:47 PM Rui Ueyama <ruiu at google.com> wrote:
> On Wed, Apr 17, 2019 at 10:42 AM Don Hinton via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> It's actually a bit weirder than you might think.  The CommandLine
parser
>> will happily eat as many dashes as you care to write, e.g.,
`----sections`
>> is the same as `-sections`.
>>
>
> That seems true, and I'm a bit surprised. Accepting three or more
dashes
> is definitely a bug.
>
> On Tue, Apr 16, 2019 at 2:11 AM James Henderson via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> As I think I said elsewhere, I find it weird that LLVM tools accept
long
>>> arguments with a single dash, and I'd be happy for the binary
utilities at
>>> least to move away from this approach, if it improves
compatibility/reduces
>>> gotchas etc. One of the points from the BoF on the LLVM binutils at
the
>>> recent Euro LLVM developers' meeting was that if we are going
to break
>>> compatibility with previous versions of LLVM, we're better off
doing it
>>> now, rather than leaving it a long time. The longer it gets left,
the more
>>> users, and therefore the more likely somebody has come to rely on
it in a
>>> non-trivial-to-fix way.
>>>
>>> If we are particularly concerned with llvm-readobj, we could (if it
is
>>> practical) try handling it differently to llvm-readelf. An approach
as
>>> suggested by Michael Spencer at the BoF could be to migrate away
from using
>>> cl::opt and follow the same route as llvm-objcopy. That would allow
us to
>>> have different option sets for the two versions of that tool, if we
wanted.
>>>
>>> On Tue, 16 Apr 2019 at 08:44, Jordan Rupprecht <rupprecht at
google.com>
>>> wrote:
>>>
>>>> For binutil compatibility, and in general for any new tools,
this
>>>> sounds reasonable to me. But I'd worry that things like
llvm-readobj have
>>>> existed for a long time and people are used to flags like
"-sections", and
>>>> it may be complicated to change that now. (I guess this RFC is
a check to
>>>> see if this is true for anyone on the mailing list).
>>>>
>>>> What happens if you make this change and someone does use
"-sections"
>>>> -- will the command line parser suggest "--sections",
or will it just fail
>>>> because one of -s, -e, -c, etc. is not a valid option?
>>>>
>>>> On Tue, Apr 16, 2019 at 9:00 AM Rui Ueyama via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> That change makes sense to me. I'd like to note that
the policy should
>>>>> be set per-command basis, as some commands are required to
accept both `--`
>>>>> and `-` for long option names. lld is such command.
>>>>>
>>>>> On Tue, Apr 16, 2019 at 3:41 PM Fāng-ruì Sòng via llvm-dev
<
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Many llvm utilities use cl::ParseCommandLineOptions()
>>>>>> (include/Support/CommandLine.h) to parse command line
options. The cl
>>>>>> library accepts both -long-option and --long-option
forms, with the single
>>>>>> dash form (-long-option) being more popular.
>>>>>>
>>>>>> We also have many binary utilities (llvm-objcopy
llvm-objdump
>>>>>> llvm-readobj llvm-size ...) whose names reflect what
they imitate. For
>>>>>> compatibility with GNU binutils (and some Unix
utilities transitively),
>>>>>> these utilities accept many short options. People who
use llvm utilities as
>>>>>> replacement of GNU binutils may use the grouped option
syntax (POSIX
>>>>>> Utility Conventions), e.g. -Sx => -S -x, -Wd =>
-W -d, -sj.text => -s
>>>>>> -j.text
>>>>>>
>>>>>> The problem is, grouped short options don't play
well with
>>>>>> -long-option. Sometimes there can be ambiguity. The
issue is more prominent
>>>>>> if the short option accepts an argument.
>>>>>>
>>>>>> An approach to prevent the ambiguity is to just
disallow -long-option.
>>>>>> In D60439, I plan to make llvm-objcopy accept
--long-option but not
>>>>>> -long-option.
>>>>>> It will make its command line option parsing behave
more like GNU
>>>>>> objcopy and less like a regular llvm utility. What do
people think of the
>>>>>> divergence?
>>>>>>
>>>>>> Further, can we make similar changes to other llvm
binary utilities
>>>>>> (their names give people the expectation), especially
those with many short
>>>>>> options such as llvm-objdump and llvm-readobj?
llvm-readobj behaves like
>>>>>> GNU readelf if you name it "llvm-readelf". (I
don't suggest disallowing
>>>>>> -long-option for utilities other than binutils)
>>>>>>
>>>>>> (Note, llvm-objcopy is a new member of the family and
it uses
>>>>>> tablegen based include/llvm/Option/Opton.h, instead of
cl:: as other
>>>>>> utilities do.)
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 宋方睿
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190416/04442b25/attachment.html>