public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Lewis Hyatt via Gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] driver: Improve the generated help text for alias options with arguments
Date: Mon, 16 Mar 2020 18:11:08 +0000	[thread overview]
Message-ID: <mptzhcg6ugz.fsf@arm.com> (raw)
In-Reply-To: <20200315135300.GA32701@ldh-macbook.local> (Lewis Hyatt via Gcc-patches's message of "Sun, 15 Mar 2020 09:53:00 -0400")

Lewis Hyatt via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> Hello-
>
> Currently, if an option is both undocumented and an alias for a second option,
> the help text generated by gcc --help directs the reader to use the other
> option instead. This makes sense for deprecated options, but it seems this
> pattern is also used for another case, namely when an option exists so as to
> pass a default argument to another option. For instance this one, from
> common.opt:
>
> -------------
> fdiagnostics-color
> Common Alias(fdiagnostics-color=,always,never)
> ;
>
> fdiagnostics-color=
> Driver Common Joined RejectNegative Var(flag_diagnostics_show_color) Enum(diagnostic_color_rule) Init(DIAGNOSTICS_COLOR_NO)
> -fdiagnostics-color=[never|always|auto]	Colorize diagnostics.
> -------------
>
> This is nice because it means you can say -fdiagnostics-color as a shorthand
> for -fdiagnostics-color=always, or -fno-diagnostics-color as a shorthand for
> -fdiagnostics-color=never. However, the generated help text does not describe
> it this way:
>
> -------------
> $ gcc --help=common | grep fdiagnostics-color
>   -fdiagnostics-color         Same as -fdiagnostics-color=.  Use the latter option instead.
>   -fdiagnostics-color=[never|always|auto] Colorize diagnostics.
> -------------
>
> Perhaps I am wrong and the non-argument usage is indeed meant to be deprecated,
> but it feels more like it was intended as a convenience and could be documented
> as such. What actually prompted this patch is that I am adding a new option for
> GCC 11 with these never/always/auto semantics and I am a bit confused whether I
> am supposed to add the aliased version or not. Feels like it's nice to add it,
> but then the --help output says the opposite...
>
> Anyway, the attached patch would change the help output to the following... If
> that seems to be an improvement and closer to the intended behavior, please let
> me know. Thanks!
>
> -------------
>   -fdiagnostics-color         Same as -fdiagnostics-color=always (or, in negated form, -fdiagnostics-color=never).
>   -fdiagnostics-color=[never|always|auto] Colorize diagnostics.
> -------------
>
> FWIW there are three other options currently affected by this change
> (-Wimplicit-fallthrough, -fcf-protection, and -flive-patching). The change for
> -Wimplicit-fallthrough I think is particularly helpful:
>
> -Wimplicit-fallthrough      Same as -Wimplicit-fallthrough=.  Use the latter option instead.
> becomes
> -Wimplicit-fallthrough      Same as -Wimplicit-fallthrough=3 (or, in negated form, -Wimplicit-fallthrough=0).

I also see:

-  -ftail-call-workaround      Same as -ftail-call-workaround=.  Use the latter option instead.
+  -ftail-call-workaround      Same as -ftail-call-workaround=1 (or, in negated form, -ftail-call-workaround=0).
   -ftail-call-workaround=<0,2> Disallow tail call optimization when a calling routine may have omitted character lengths.
...
   --imacros                   Same as -imacros.  Use the latter option instead.
   --imacros=                  Same as -imacros.  Use the latter option instead.
   --include                   Same as -include.  Use the latter option instead.
-  --include-barrier           Same as -I.  Use the latter option instead.
+  --include-barrier           Same as -I-.
   --include-directory         Same as -I.  Use the latter option instead.
   --include-directory-after   Same as -idirafter.  Use the latter option instead.
   --include-directory-after=  Same as -idirafter.  Use the latter option instead.
...
-  -Wnormalized                Same as -Wnormalized=.  Use the latter option instead.
+  -Wnormalized                Same as -Wnormalized=nfc (or, in negated form, -Wnormalized=none).
   -Wnormalized=[none|id|nfc|nfkc] Warn about non-normalized Unicode strings.

I agree all of these look like improvements, especially the
--include-barrier one.  But I think the include ones also show
that the "Use the latter option instead." decision is independent
of whether the option is defined to be an alias.

FWIW, there's also:

Wmissing-format-attribute
C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format)
;

which still ends up as:

  -Wmissing-format-attribute  Same as -Wsuggest-attribute=format.  Use the latter option instead.

Not really my area though, so I don't have any specific suggestion
about how to separate the cases.

Thanks,
Richard

  reply	other threads:[~2020-03-16 18:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-15 13:53 Lewis Hyatt
2020-03-16 18:11 ` Richard Sandiford [this message]
2020-03-16 22:11   ` Lewis Hyatt
2020-03-16 22:21     ` Lewis Hyatt
2020-03-17 11:52     ` Richard Sandiford
2020-03-20 12:24       ` Lewis Hyatt
2020-03-20 12:54         ` Richard Sandiford
2020-03-20 16:06       ` Martin Sebor
2020-03-20 17:46         ` Richard Sandiford
2020-03-20 19:16           ` Martin Sebor
2020-03-20 21:02             ` Lewis Hyatt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mptzhcg6ugz.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).