Use bpaf for argument parsing

[yerke]

Use bpaf crate for argument parsing. Currently this PR is for discussion purposes only.

Relates to #458

[yerke]

@davidlattimore I spent some time reading bpaf docs and tutorials. I think I understand how @pacak intended for it to be used. But that vision is different from what you described in #458, where you propose to manually consume arguments.

Can you please explain how you want execute() part to be implemented from your examples? I am not sure I figured a way to do it with bpaf.

parser
   .declare()
   .long("static")
   .long("Bstatic")
   .help("Disallow linking of shared libraries")
   .execute(|| {
     modifier_stack.last_mut().unwrap().allow_shared = false;
  });

Another question: is it a valid combination to parameters to provide both --gc-sections and --no-gc-sections? They contradict one another, but the current parser will consume the last one and be happy.

Thanks.

[davidlattimore]

I spent some time reading bpaf docs and tutorials. I think I understand how @pacak intended for it to be used. But that vision is different from what you described in #458, where you propose to manually consume arguments.

Yep, the initial common comment on the issue was one design that was not using any 3rd party argument parsing libraries. The later comments should supercede that design. If using bpaf turns out to not work so well for some reason, then we might want to fall back to the original design, but otherwise you can disregard it.

Another question: is it a valid combination to parameters to provide both --gc-sections and --no-gc-sections? They contradict one another, but the current parser will consume the last one and be happy.

Yes, later arguments should override earlier ones. If unsure, you can try doing the same thing with GNU ld. e.g, the following command completes without error or warning:

gcc -Wl,-gc-sections -Wl,-no-gc-sections main.c

[lu-zero]

Do we have a corpus to use to make tests?

[davidlattimore]

Do we have a corpus to use to make tests?

I find corpus based testing tends to result in lots of redundant testing. So they're good for finding problems, at which point you write a proper, minimal test for that bug, but I wouldn't want to be running on a large test corpus with every PR for example. But I guess given that you're commenting on this PR, you're talking about specifically for argument parsing? There's some existing tests, although we could probably benefit from a few more. But I'd say the argument for hand-writing them would be even stronger there.

[lu-zero]

I find corpus based testing tends to result in lots of redundant testing. So they're good for finding problems, at which point you write a proper, minimal test for that bug, but I wouldn't want to be running on a large test corpus with every PR for example.

Yes :)

But I guess given that you're commenting on this PR, you're talking about specifically for argument parsing? There's some existing tests, although we could probably benefit from a few more. But I'd say the argument for hand-writing them would be even stronger there.

Recently I got a request to minimize/normalize link lines in cargo-c so I was looking exactly at those corner cases to explain why collecting the arguments in a set may lead to wrong results.

[lapla-cogito]

FYI: I proposed a different approach. The choice of which approach to use remains open for consideration. #1029

[lu-zero]

It is a bit reinventing the wheel, but given that this PR is on hold since a long time...

[davidlattimore]

We can still potentially switch to bpaf in future

[lapla-cogito]

While it may initially appear that we're reinventing the wheel, there are several subtle requirements that existing argument parser frameworks like clap or bpaf cannot fulfill—primarily to maintain compatibility with existing linkers such as GNU ld.
For example, we'd like to support parsing long options even when they use a single hyphen (which would require using any parser for almost all options in bpaf, or employing workarounds like .alias() in clap). We also need to handle options with side effects, such as those that manipulate a stack for storing flag states (like --push-state and --pop-state).

[davidlattimore]

There are ways to meet those requirements with bpaf. See comments by pacak on #458. I guess the question then would be whether the code to do these with bpaf is more or less readable than the without bpaf.

[lu-zero]

Given the helper shown in #458 I would expect bpaf to be much more straightforward. If @yerke is busy I can try to give it a go myself.

[davidlattimore]

Given the helper shown in #458 I would expect bpaf to be much more straightforward. If @yerke is busy I can try to give it a go myself.

By all means. That'd be good to see what it'd look like with bpaf. We wouldn't want to use an external crate for argument parsing just for the sake of it though, so we'd only want to merge it if it gave us some benefit like better error messages or substantially simpler code.

[marxin]

Given the age of the PR and the fact it conflicts with the main, can we please close the PR? Similarly to @davidlattimore, l am open to the integration of the bpaf in the future. Thanks.