user --help should override built-in about chapel HOT 7 OPEN

It seems odd that the example has an 'if false' - is that and error in the example? I suppose that either way you see the compiler-generated help.
Anyway a good example of user-overriding confit help should also call Help.printUsage() (from the Help standard module).

from chapel.

Oops, I think what happened was that I changed the test to 'true' to verify the .good file and then switched it to 'false' instead of 'help' when setting it back again.

I'm not sure I agree that good examples of providing custom help should necessarily call Help.printUsage()... I.e., maybe that's not what they would want the help message to look like.

from chapel.

With the addition of the ArgumentParser module in v1.25, do we still want to try to support this behavior?

from chapel.

@arezaii : I'm not seeing how the addition of ArgumentParser changes the root issue here (that defining a config whose name happens to match a built-in flag silently loses to that flag). Does it?

from chapel.

No, you're right, it doesn't address this issue where a config shadows a built-in. I was imagining the user could handle the --help flag with the ArgumentParser instead of a config.

Do you envision a fix for this to handle just the --help flag, or all/any Chapel defined flags, or maybe some other subset of flags?

from chapel.

I don't have a specific fix in mind, but I think the current behavior could potentially be pretty confusing to a user. I think with this specific case, it's easy to say "Well, the user should just use one of the other help capabilities that we support to get the help message they want", but I think the larger issue is that they may be using a config named help to do something other than print out help / may not know about those features / may run into this with other similar flags.

So a very simple short-term fix would be to generate a warning for such configs indicating that they're shadowed by other built-in flags and that the user will have to use -s or a fully-qualified --moduleName.help= flag to set them (or should rename the variable to avoid the shadowing).

Longer-term, this relates to the discussion we've been having about the interaction between built-in flags (whether for built-in configs or other features) and arguments sent to main().

from chapel.

Longer-term, this relates to the discussion we've been having about the interaction between built-in flags (whether for built-in configs or other features) and arguments sent to main().

@arezaii - I'm not finding a public issue about this topic specifically. I know we had some discussion in https://github.com/Cray/chapel-private/issues/2289 though. Would you be able to open a public issue asking how built-in flags should interact with arguments sent to main?

from chapel.