sponge command throwing error with no subcommand

[phit]

I am currently running

• SpongeForge version: 7.1.0-BETA-3218
• SpongeVanilla version: 1.12.2-7.1.0-BETA-67

• Plugins/Mods: /

Issue Description
type /sponge in console, get reply

[02:41:45] [Server thread/INFO]: Invalid subcommand state -- no more than one mapping may be provided for child arg child0

expected result

[02:40:10] [Server thread/INFO]: Not enough arguments!
[02:40:10] [Server thread/INFO]: Usage: /sponge which|audit|plugins|timings|heap|version|[--global|-g] [--world|-w <world>] [--dimension|-d <dimension>] reload|chunks|tps|save|config

[SimonFlash]

The problem here is that Sponge's CommandElement for non-flag children is created with a fallback executor but not a CommandElement to handle the parsing for it (here). This causes the parse method to return without handling the verification that a subcommand has been specified as there's no fallback element (here).

The solution to this is to create the ChildCommandElementExecutor with the delegate element as both the fallback executor and fallback element.

final ChildCommandElementExecutor flagChildren = new ChildCommandElementExecutor(null);
final ChildCommandElementExecutor nonFlagChildren = new ChildCommandElementExecutor(flagChildren, flagChildren, true);

[ryantheleach]

Considering it was working previously, is @SimonFlash 's suggestion a work around? or is the current behavior unintended given the current command code?

[dualspiral]

Workaround should work - at least ish, though I don't think it'll give the correct usage (I think, haven't tested it, this is skimming code while in bed), reasoning is not completely correct.

Note that these child commands are not written in the normal way. The children arguments are specified differently, so the expectation is that these arguments should create the usage. As firstParsing is creating the commands, that should bail without parsing any commands - obviously it is not. This is probably because I've got some check for standard child commands that has messed up in this case, likely due to improper validation that Simon suggested.

I'll fix it either tonight or this weekend.