Re: C++ PATCH: Fix PR 862

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jason" == Jason Merrill <jason_merrill@redhat.com> writes:

    Jason> I would doubt that, but in any case I don't think the
    Jason> specific degree of brokenness is the issue; I don't see the
    Jason> problem with having flags for functionality that is still
    Jason> under development.  -fnew-abi comes to mind.  Or, more
    Jason> similarly, -fssa.

True -- for the development mainline.  I think there's little point in
having known broken flags (like -fssa) in releases.  In fact, that
reminds me that -fssa should probably go away on the branch.  I think
from what you say that you agree, right?

    Jason> I agree that this flag should be documented, but I'm not
    Jason> sure all flags should be; is it actually useful to say
    Jason> "here's this flag, don't use it"?

I predict Joseph will disagree with you.

And anyhow I do. :-) 

Now, what might be good is to mark the flag with some TeXinfo
conditional so that it only shows up in a developers-only view of the
document.

(With -fvtable-gc, part of the documentation problem is that even the
in-code documentation is suboptimal:

  /* Nonzero means output .vtable_{entry,inherit} for use in doing
     vtable gc.  */

In other words, -fvtable-gc means to do "vtable gc".  I think we can
do better. :-) )

Here's another way to look at it:

  - If we document the option in invoke.texi on the mainline, then
    when we decide to make the feature part of a release, we're
    all ready to go.  Otherwise, we've just deferred that effort
    and made it likely that we'll forget.  And if we don't, we're
    making it likely that someone other that the party that should
    have been responsible will have to pick up the pieces.

    I just wrote documentation for a bunch of flags, none of which 
    I implemented, some of which I don't even like, and some of which
    I didn't manage to clearly understand, given Fergus' comments.

I think we should document flags in invoke.texi the moment they go
into the compiler.  If nothing else, that will force us to clearly
define what the purpose of the option is, in English.  If we can't do
that, then the option is not even ready to be in the development
stage.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com