Make pony programs exit on an unrecognized pony runtime option

[dipinhora]

Prior to this commit, if someone passed an unrecognized pony runtime option (due to a typo or otherwise), the pony program would silently ignore the argument and keep running without the operator knowing that the intended pony runtime option wasn't applied.

root@5babe01f566f:/workspaces/ponyc# ./helloworld --ponyblah
Hello, world.
root@5babe01f566f:/workspaces/ponyc#

This commit changes things so that pony programs will now print out an error message and exit with a non-zero exit code when an unrecognized pony runtime option is supplied:

root@5babe01f566f:/workspaces/ponyc# ./helloworld --ponyblah
./helloworld: Unrecognised pony runtime option: '--ponyblah'!
Run './helloworld --ponyhelp' for available pony runtime options.
root@5babe01f566f:/workspaces/ponyc#

[ponylang-main]

Hi @dipinhora,

The changelog - added label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.

Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 4622.md to match the number of this pull request.

The basic format of the release notes (using markdown) should be:

## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

[SeanTAllen]

As the tests indicate, this will break things. Any program that uses a CLI that starts with --pony is going to get whacked like the full test program runner as an example. I think the intent of this is good, but I don't think that claiming every flag that starts with "pony" as being "runtime only" is a good idea.

[dipinhora]

As the tests indicate, this will break things. Any program that uses a CLI that starts with --pony is going to get whacked like the full test program runner as an example. I think the intent of this is good, but I don't think that claiming every flag that starts with "pony" as being "runtime only" is a good idea.

fair enough.. although the current situation seems like a recipe for disaster where a new pony runtime option might get added that silently takes precedence over an existing option in a pony program..

[SeanTAllen]

@dipinhora agreed, that is also a problem. I think it is worth a discussion so I am reopening and it can be gone over at the next sync.

[SeanTAllen]

@dipinhora can you rebase this against main?

[SeanTAllen]

If we decide we want to reserve all of --pony* then I think as part of this PR, we should note the reservation as part of the CLI package. As @jemc points out, Env.args should have similar documentation.

[SeanTAllen]

When this is rebased against main, the CI should be successful.

[SeanTAllen]

Consensus on the sync call is in favor of this @dipinhora. Please proceed.

[dipinhora]

@dipinhora can you rebase this against main?

rebased..

If we decide we want to reserve all of --pony* then I think as part of this PR, we should note the reservation as part of the CLI package. As @jemc points out, Env.args should have similar documentation.

can you folks please suggest the wording desired? also, i'm not familiar with the cli package.. where in the cli package should the note be added?

[SeanTAllen]

I looked at the CLI docs and I don't think there is a good place for a note there. Certainly nothing that I can see adding value. I think it is reasonable for us to reconsider.

Given that all new usage of flags will result in an error when someone tries to use then perhaps the correct place is part of the error message that Dipin has added here. "If you tried to add a flag starting with --pony ... etc etc".

I think that having in that error message rather than tucked away in CLI and Env docs will result in a better experience for anything tripping over --pony* being reserved for the runtime.

And in addition to that, we have the release notes to make the breaking change clear in the case of existing programs that might break.