New Issue: How should built-in flags interact with arguments sent to main?

18560, "arezaii", "How should built-in flags interact with arguments sent to main?", "2021-10-12T22:53:05Z"


Chapel defines several built-in flags which can typically be viewed using ./chapelProgram --help. (output below)

A user may define config vars/consts whose names shadow these built-in flags. Common cases are help, verbose, quiet, about, etc.

At present, there is no warning to a user that they have defined a config that shadows a built-in. This can lead to confusing behavior, as described in #4973, #12021.

A shadowed config can be disambiguated by using -s<config> or --<config>=<value>, but this is not immediately clear to the user and there is no way to force a flag like --quiet to always be used for their config.

Additionally, a developer may define main to accept arguments by declaring it in the form main(args: [] string) { }. In the case of Chapel defined flags other than -h/--help, any shadowed flags will be consumed by the Chapel runtime before being passed to main.

As a workaround, a shadowed flag can be recognized by adding a -- delimiter before the flag meant for main, in which case the runtime will forward everything after the delimiter to main. However, the requirement of adding a -- prior to shadowed flags meant for main may not be desirable.

We would like to identify a solution that gives the developer flexibility in how they implement their configs and/or argument parsing in a way that preserves access to built-in flags or bypasses Chapel runtime parsing in whole or in part.

Possible Solutions

These are some solutions that have been proposed so far:

From #12021 (although this would likely apply to all built-ins):

  1. We could have the user's verbose take precedence over the built-in --verbose flag. This has the upside of being less surprising, but the downside of not providing a(n obvious) way to get a Chapel's verbose flag.
  2. We could define Chapel's --verbose flag as a config const itself in a well-defined standard module, such normal module disambiguation rules would kick in and the user would have to select between --testit.verbose or --ChplFlags.verbose (or whatever we call the module)
  3. We could take option 2 but have the user module take precedence over the built-in Chapel module such that the user had the convenience of option 1, but still had a means of getting to the Chapel flag.

Launcher Flags

While most of these flags can be overridden without much concern, there are some flags whose processing cannot be delayed because they are needed to configure the launcher, namely -nl/numLocales and -E. It has been suggested that since -E is not supported for general use, that we can safely rename it to --chplEnv or similar. That leaves -nl/--numLocales and --chplEnv (or whatever -E becomes) as reserved exclusively for the Chapel runtime.

Related Issues

Chapel Defined Flags

For reference, here is the standard output from ./chapelProgram --help listing the Chapel configs: