possible red flag for new C++ parser

[Tom Lord]

       Karel:

       I'm afraid Tom, you don't understand. Small explanation: old
       parser was more tolerant to some code which wasn't strickly ISO
       C++, while the new parser correctly reports errors. So the
       problem will be that you'll end with tons of regressions
       against new parser while the problem is in wrong C++ code of
       compiled packages.

Wow.  (I've just been googling around to catch up on the state of C++
in the world.)   Quite a pickle.

Let me assume for the moment that your concern is not exaggerated.
That's a huge problem for everyone, much larger in scope than GCC.

Let's consider that problem from the perspective of free software
vendors and the GNU project.  If a more accurate GCC is going to break
lots of free software packages, that's a really big deal.  For
example, are Linux vendors and projects like Debian going to have to
build and ship with multiple GCC versions for a long period while the
various projects "catch up" to the new GCC?  What is that going to do
to their costs and to their customer satisfaction?  For the GNU
project, while the new parser might be a quality step forward, it
might also be a practical step backwards.  At the very least, it seems
like the kind of event these parties would want to plan for carefully.
In the extreme, perhaps it will be worth the cost of writing a 
special C++ lint just for this transition.

The circumstance doesn't much change my analysis of project
management, though.

Ok, so -- start with some large body of real world code and reduce it
to the C++ packages that compile with the old parser.

Then try with the new parser.

It would be interesting, first, to measure the number of possible
regressions, then to sample them to get some idea of how they line up.

Statistical sampling might reveal that:

	1) Most apparent regressions aren't regressions at all, but
           are bugs in the C++ code that the old parser didn't catch. 
           (false regressions)

	2) Most apparent regresssions are regresssions -- cases of
           good code that the new parser fails on.  (true 
           regressions)

	3) Somehere in the middle between (1) and (2).


If (1) or (3) is the case, and the number of possible regressions is
large, then the vendors and the GNU project have a big problem.

For GCC itself:

If (2) is the case -- that's easy.  The analysis I already gave
applies directly.  The goal is to fix bugs and resample the apparent
regressions until (2) is no longer the case.  If there are ample
volunteers doing testing and analysis, then at the same time you can
be eliminating buggy packages from the test suite at a snappy rate --
simultaneously converging on both a good test suite and a
regression-less parser.

If (1) is the case -- that means the body of real world code is
useless for testing the parser and a different set of potential tests
has to be found.  (And, pity the maintainers of that body of code.)

If (3) is the case, then the nature of the "false regressions" has to
be studied.  It may be the case that there are just a few kinds of
package bug that explain most of the false regressions.  If so,
perhaps they can be easilly eliminated from the test suite.  If not,
then this isn't much different from (1).

My understanding is that the new parser is much faster and more
compliant.  The costs of picking some body of code and doing the
sampling are pretty moderate in the grand scheme of things -- a few
man months, I'd think.  The payoff is large.  This seems to me like
the kind of thing that the SC should (regularly) be able to ask the
vendors to pony up for -- that kind of spending path and decision
making path should be optimized.

And in any event, there's (ultimately, if the tools and processes
were better) no need to go through this kind of thing on the trunk.

-t