[v3,00/10] fix bug, use more enums

Message

Ævar Arnfjörð Bjarmason Oct. 8, 2021, 7:07 p.m. UTC

A re-roll of
https://lore.kernel.org/git/[e-mail]/;
I dropped the addition of exhaustive enum arms for parse_opt_type.

There's other tweaks here pointed out by Junio & René, thanks both!
The "enum parse_opt_flags flags" change in the range-diff below was
there before, but it was (incorrectly, to begin with) in the
now-dropped patch.

Ævar Arnfjörð Bjarmason (10):
  parse-options.h: move PARSE_OPT_SHELL_EVAL between enums
  parse-options.[ch]: consistently use "enum parse_opt_flags"
  parse-options.[ch]: consistently use "enum parse_opt_result"
  parse-options.c: use exhaustive "case" arms for "enum
    parse_opt_result"
  parse-options.h: make the "flags" in "struct option" an enum
  parse-options.c: move optname() earlier in the file
  commit-graph: stop using optname()
  parse-options.[ch]: make opt{bug,name}() "static"
  parse-options tests: test optname() output
  parse-options: change OPT_{SHORT,UNSET} to an enum

 builtin/blame.c          |  3 ++
 builtin/commit-graph.c   |  4 +-
 builtin/shortlog.c       |  3 ++
 parse-options.c          | 87 ++++++++++++++++++++++------------------
 parse-options.h          | 26 ++++++------
 t/t0040-parse-options.sh | 42 +++++++++++++++++--
 6 files changed, 109 insertions(+), 56 deletions(-)

Range-diff against v2:
 1:  553931702df =  1:  59195845497 parse-options.h: move PARSE_OPT_SHELL_EVAL between enums
 2:  99f5251c557 !  2:  d4aaaa645de parse-options.[ch]: consistently use "enum parse_opt_flags"
    @@ Commit message
         Use the "enum parse_opt_flags" instead of an "int flags" as arguments
         to the various functions in parse-options.c.
     
    -    In C enums aren't first-class types, and the "enum
    -    parse_opt_option_flag" uses a enum-as-bitfield pattern. So unlike
    -    exhaustively enumerated "case" arms we're not going to get validation
    -    that we used the "right" enum labels.
    -
    -    I.e. this won't catch the sort of bug that was fixed with
    -    "PARSE_OPT_SHELL_EVAL" in the preceding commit.
    -
    -    But there's still 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":
    +    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:
     
    @@ parse-options.h: struct option {
      NORETURN void usage_with_options(const char * const *usagestr,
      				 const struct option *options);
     @@ parse-options.h: struct parse_opt_ctx_t {
    + 	const char **out;
    + 	int argc, cpidx, total;
    + 	const char *opt;
    +-	int flags;
    ++	enum parse_opt_flags flags;
    + 	const char *prefix;
    + 	const char **alias_groups; /* must be in groups of 3 elements! */
    + 	struct option *updated_options;
    +@@ parse-options.h: struct parse_opt_ctx_t {
      
      void parse_options_start(struct parse_opt_ctx_t *ctx,
      			 int argc, const char **argv, const char *prefix,
 3:  be198e42df9 =  3:  828e8b96574 parse-options.[ch]: consistently use "enum parse_opt_result"
 4:  a253db7a60d =  4:  bebf3448c49 parse-options.c: use exhaustive "case" arms for "enum parse_opt_result"
 5:  467828780d0 <  -:  ----------- parse-options.c: use exhaustive "case" arms for "enum parse_opt_type"
 6:  34669327550 =  5:  23e62d4139f parse-options.h: make the "flags" in "struct option" an enum
 7:  e82a4e477d5 =  6:  7afdb22885d parse-options.c: move optname() earlier in the file
 8:  58683b3d89d !  7:  67a9b38f66c commit-graph: stop using optname()
    @@ Commit message
         of "opt->flags" to optname(), that function expects flags, but not
         *those* flags.
     
    +    Let's pass "max-new-filters" to the new error because the option name
    +    isn't translatable, and because we can re-use a translation added in
    +    f7e68a08780 (parse-options: check empty value in OPT_INTEGER and
    +    OPT_ABBREV, 2019-05-29).
    +
         Signed-off-by: Ævar Arnfjörð Bjarmason <[e-mail]>
     
      ## builtin/commit-graph.c ##
    @@ builtin/commit-graph.c: static int write_option_max_new_filters(const struct opt
      		if (*s)
     -			return error(_("%s expects a numerical value"),
     -				     optname(opt, opt->flags));
    -+			return error(_("option `max-new-filters' expects a numerical value"));
    ++			return error(_("option `%s' expects a numerical value"),
    ++				     "max-new-filters");
      	}
      	return 0;
      }
 9:  8cbee660174 =  8:  520cc5a8dc0 parse-options.[ch]: make opt{bug,name}() "static"
10:  f727f683eb1 =  9:  a82987a03c7 parse-options tests: test optname() output
11:  4fbc07fc7fd = 10:  e05627d3634 parse-options: change OPT_{SHORT,UNSET} to an enum