Accept subcomands as last element in x.py argv

[estebank]

Fix #38373.

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[nagisa]

I think we should still just use a proper argument parser. The thing is that while

python x.py --stage 1 test

is a valid command

python x.py --stage 1 test src/libstd

is also valid, and will not work with this patch.

[estebank]

You're right, but then there would be parsing code in two different places, in two different languages. This seemed like a quick workaround for the time being. I was already uneasy about having the list of subcommands there.

I could also look for the presence of a subcommand and move everything that comes after to the front of the argv list. This is still not ideal and could break, but seems to me like a close enough heuristic that would not be broken now and that would relief this annoyance in the meantime without having to duplicate argv parsing code in Python and Rust.

[nagisa]

Is it even necessary for python part to parse any arguments? Why can’t it just pass them through (and rustbuild (the rust part) properly handle everything)?

[alexcrichton]

Thanks for the PR! I think that the bug though lies not in the python script but rather here in the Rust code. Python's correctly forwarding all arguments and not interpreting them, but the problem is that we have a different set of flags for each subcommand, so we don't know how to parse the arguments until we figure out the subcommand. We can likely be more clever on that line, though!

We could perhaps use the StopAtFirstFree mode of getopts to use the "base" set of flags and assume that no subcommand-specific flags like --test-args come before the subcommand. That way we could parse the arguments, learn the subcommand, then reparse the arguments with the known set of flags afterwards.

[nagisa]

Or migrate to clap :)