This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [DOCPATCH] change from opus: 3.3 and almost mainline


On Wed, 16 Jul 2003, James Morrison wrote:
> 2003-04-23  Lisa M. Opus Goldstein  <opus@gnu.org>
>
>         * doc/invoke.texi: Fixes to style, grammar and diction.

I had a look, and some of these changes really are very nice
improvements!

Only about three of them, I am not sufficiently confident.

> -Names of template functions whose types involve @code{typename} or
> -template template parameters can be mangled incorrectly.
> +Template functions whose template parameters involve @code{typename} or
> +@code{template} may have their names mangled incorrectly.


>  @item -Wno-pmf-conversions @r{(C++ only)}
>  @opindex Wno-pmf-conversions
> -Disable the diagnostic for converting a bound pointer to member function
> -to a plain pointer.
> +Disable the diagnostic for a bound pointer to member function
> +that is converted into a plain pointer.


>  during compilation.  Because these checks scan the method table only at
>  the end of compilation, these warnings are not produced if the final
> -stage of compilation is not reached, for example because an error is
> -found during compilation, or because the @code{-fsyntax-only} option is
> +stage of compilation is not reached (i.e., an error is
> +found during compilation) or because the @code{-fsyntax-only} option is
>  being used.

Transforming "for example" to "i.e." seems unsafe, in general.  Are you
sure it is okay here?


> @@ -1839,8 +1839,8 @@
>  below can be used to control the diagnostic messages formatting
>  algorithm, e.g.@: how many characters per line, how often source location
>  information should be reported.  Right now, only the C++ front end can
> -honor these options.  However it is expected, in the near future, that
> -the remaining front ends would be able to digest them correctly.
> +honor these options.  However, it is expected in the near future that
> +the remaining front ends will be able to digest them correctly.

How about: "However, we expect..."  (i.e., using active voice)?


I'm very hesitant to apply the part above without explicit approval by a
language frontend maintainer (or someone qualified like Joe or Fergus),
but if you send a patch without these critical part, I will apply them
right away.

Gerald


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]