git/parse-options.h, branch v2.34.2

Merge branch 'ab/parse-options-cleanup'

2021-11-09T21:19:06Z

Last minute fix to the update already in 'master'. * ab/parse-options-cleanup: parse-options.[ch]: revert use of "enum" for parse_options()

parse-options.[ch]: revert use of "enum" for parse_options()

2021-11-09T17:45:37Z

Revert the parse_options() prototype change in my recent 352e761388b (parse-options.[ch]: consistently use "enum parse_opt_result", 2021-10-08) was incorrect. The parse_options() function returns the number of argc elements that haven't been processed, not "enum parse_opt_result". Reported-by: SZEDER Gábor Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'ab/parse-options-cleanup'

2021-10-25T23:06:59Z

Random changes to parse-options implementation. * ab/parse-options-cleanup: parse-options: change OPT_{SHORT,UNSET} to an enum parse-options tests: test optname() output parse-options.[ch]: make opt{bug,name}() "static" commit-graph: stop using optname() parse-options.c: move optname() earlier in the file parse-options.h: make the "flags" in "struct option" an enum parse-options.c: use exhaustive "case" arms for "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_flags" parse-options.h: move PARSE_OPT_SHELL_EVAL between enums

Merge branch 'ab/help-config-vars'

2021-10-13T22:15:58Z

Teach "git help -c" into helping the command line completion of configuration variables. * ab/help-config-vars: help: move column config discovery to help.c library help / completion: make "git help" do the hard work help tests: test --config-for-completion option & output help: simplify by moving to OPT_CMDMODE() help: correct logic error in combining --all and --guides help: correct logic error in combining --all and --config help tests: add test for --config output help: correct usage & behavior of "git help --guides" help: correct the usage string in -h and documentation

parse-options.[ch]: make opt{bug,name}() "static"

2021-10-08T21:13:11Z

Change these two functions to "static", the last user of "optname()" outside of parse-options.c itself went away in the preceding commit, for the reasons noted in 9440b831ad5 (parse-options: replace opterror() with optname(), 2018-11-10) we shouldn't be adding any more users of it. The "optbug()" function was never used outside of parse-options.c, but was made non-static in 1f275b7c4ca (parse-options: export opterr, optbug, 2011-08-11). I think the only external user of optname() was the commit-graph.c caller added in 09e0327f57 (builtin/commit-graph.c: introduce '--max-new-filters=', 2020-09-18). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options.h: make the "flags" in "struct option" an enum

2021-10-08T21:13:11Z

Change the "flags" members of "struct option" to refer to their corresponding "enum" defined earlier in the file. The benefit of changing this to an enum isn't as great as with some "enum parse_opt_type" as we'll always check this as a bitfield, so we can't rely on the compiler checking "case" arms for us. But let's do it for consistency with the rest of the file. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options.[ch]: consistently use "enum parse_opt_result"

2021-10-08T21:13:11Z

Use the "enum parse_opt_result" instead of an "int flags" as the return value of the applicable functions in parse-options.c. This will help catch future bugs, such as the missing "case" arms in the two existing users of the API in "blame.c" and "shortlog.c". A third caller in 309be813c9b (update-index: migrate to parse-options API, 2010-12-01) was already checking for these. As can be seen when trying to sort through the deluge of warnings produced when compiling this with CC=g++ (mostly unrelated to this change) we're not consistently using "enum parse_opt_result" even now, i.e. we'll return error() and "return 0;". See f41179f16ba (parse-options: avoid magic return codes, 2019-01-27) for a commit which started changing some of that. I'm not doing any more of that exhaustive migration here, and it's probably not worthwhile past the point of being able to check "enum parse_opt_result" in switch(). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options.[ch]: consistently use "enum parse_opt_flags"

2021-10-08T21:13:11Z

Use the "enum parse_opt_flags" instead of an "int flags" as arguments to the various functions in parse-options.c. Even though this is an enum bitfield there's there's a benefit to doing this when it comes to the wider C ecosystem. E.g. the GNU debugger (gdb) will helpfully detect and print out meaningful enum labels in this case. Here's the output before and after when breaking in "parse_options()" after invoking "git stash show": Before: (gdb) p flags $1 = 9 After: (gdb) p flags $1 = (PARSE_OPT_KEEP_DASHDASH | PARSE_OPT_KEEP_UNKNOWN) Of course as noted in[1] there's a limit to this smartness, i.e. manually setting it with unrelated enum labels won't be caught. There are some third-party extensions to do more exhaustive checking[2], perhaps we'll be able to make use of them sooner than later. We've also got prior art using this pattern in the codebase. See e.g. "enum bloom_filter_computed" added in 312cff52074 (bloom: split 'get_bloom_filter()' in two, 2020-09-16) and the "permitted" enum added in ce910287e72 (add -p: fix checking of user input, 2020-08-17). 1. https://lore.kernel.org/git/87mtnvvj3c.fsf@evledraar.gmail.com/ 2. https://github.com/sinelaw/elfs-clang-plugins/blob/master/enums_conversion/README.md Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options.h: move PARSE_OPT_SHELL_EVAL between enums

2021-09-28T23:50:42Z

Fix a bad landmine of a bug which has been with us ever since PARSE_OPT_SHELL_EVAL was added in 47e9cd28f8a (parseopt: wrap rev-parse --parseopt usage for eval consumption, 2010-06-12). It's an argument to parse_options() and should therefore be in "enum parse_opt_flags", but it was added to the per-option "enum parse_opt_option_flags" by mistake. Therefore as soon as we'd have an enum member in the former that reached its value of "1 << 8" we'd run into a seemingly bizarre bug where that new option would turn on the unrelated PARSE_OPT_SHELL_EVAL in "git rev-parse --parseopt" by proxy. I manually checked that no other enum members suffered from such overlap, by setting the values to non-overlapping values, and making the relevant codepaths BUG() out if the given value was above/below the expected (excluding flags=0 in the case of "enum parse_opt_flags"). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

help: simplify by moving to OPT_CMDMODE()

2021-09-23T17:30:43Z

As preceding commits have incrementally established all of the --all, --guides, --config and hidden --config-for-completion options are mutually exclusive. So let's use OPT_CMDMODE() to parse the command-line instead, and take advantage of its conflicting options detection. This is the first command with a hidden CMDMODE, so let's introduce a OPT_CMDMODE_F() macro to go along with OPT_CMDMODE(). I think this makes the usage information that we emit slightly worse, e.g. before we'd emit: $ git help --all --config fatal: --config and --all cannot be combined usage: git help [-a|--all] [--[no-]verbose]] [[-i|--info] [-m|--man] [-w|--web]] [] or: git help [-g|--guides] or: git help [-c|--config] [...] $ And now: $ git help --all --config error: option `config' is incompatible with --all $ But improving that is a general topic for parse-options.c improvement, i.e. we should probably emit the full usage in that case. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano