Parser refactor.

[ldm0]

A little parser refactor.

Fixes #1026, check tests/grouped_values.rs for the results.
Fixes #1374, check tests/grouped_values.rs:issue_1374().
Fixes #2171, check tests/grouped_values.rs:issue_2171().

[ldm0]

One sad thing is that the clippy warning make CI red is removed in currently nightly clippy but we have to deal with it in 1.46.0. :-P rust-lang/rust-clippy#6313

[ldm0]

This also fixes #2229, add tests later.

Edit:
Nope, will fix this in another patch.

[ldm0]

Hmm, sorry this PR is a bit long... The reason it because I need to prove that this refactor makes it easy for future bug solving and feature implementing, which I prove it in the last few commits. But it make this PR hard to review. I'll seperate it into several commits later.

[pksunkara]

Do you have a solution for #1794 on top of this parser refactor? I don't want to revert the fix without any other fix.

[ldm0]

Do you have a solution for #1794 on top of this parser refactor? I don't want to revert the fix without any other fix.

@pksunkara

But that's a fragile fix(I don't think it's a fix actually). I showed you the bad case in that issue comment. The inner detail is that the parser is using a positional counter to determine which positional argument should take current value. And also, the group validation is processed after all parsing is done. This is the reason of #1794, the parser cannot access arg group info in the parsing stage so it puts the value in pos1 even with the --option presented.

Now let's look at how #1856 fix this. It introduces the maybe_inc_pos_counter. It's behaviour is when you see a flag which is in a group with other positional args, increases the positional counter by the number of other positional args.

Do you notice the problem? It just increases the positional counter rather than effectively avoiding the parser pushing value to the sibling positional args or stealing already pushed value from sibling positioal args. Which causes the problem I pointed in the issue comment, just with a little change to the test case, this kind of hacky workaround will fail.

This is the design problem, and won't have an easy fix until the parser have the ability to steal the value from an arg to another, which needs a redesign of our parser. And the problem will only occur when a user groups a flag with positional argument. I don't like reverting fixes either, but I have to :

1. Current fix is bad, totally fixing it needs a deeper refactor.
2. Current fix make the code hard to read and change.

Hope you understand...

[pksunkara]

Okay, but do you have an idea (even though it's not implemented yet) on how to fix it and are going to work it on soon?

[ldm0]

Okay, but do you have an idea (even though it's not implemented yet) on how to fix it and are going to work it on soon?

@pksunkara There are several options on fixing this. For example, we can push all of the parsed positional values to a vector and pushing them to each positional arguments at last(there are more details). Another option is validating on each parsing stage, and rollback on parsing failure.

[pksunkara]

I don't think the last commit needs to be in this PR. Please make a separate one once this is merged.

[pksunkara]

Oh, so first #2320? I thought this was first. Got it.

[ldm0]

Ok, these are last bits(hard to be split) @pksunkara

[pksunkara]

Aren't the last 2 commits for different things?

[ldm0]

Aren't the last 2 commits for different things?

It seems that only the last commit is for different thing(previous commits are all doing one thing: grouped values). The last commit is based on previous commits, and also it's acceptable if previous commits is acceptable. So seperating out it is not that meaningful.

[pksunkara]

Looks good. I guess users would need grouped_values_of only when they have both MultipleValues and MultipleOccurrences turned on, right?

Maybe we should have a better name for that?