[www-patch] bugs.html rewrite,part 7: new section "Bugs fixed in the upcoming 3.4.0 release"

[Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>]

The following patch fixes the C++ section of "Frequently Reported Bugs in GCC"
in bugs.html.

In addition to "Missing features" this patch introduces a new section
"Bugs fixed in the upcoming 3.4.0 release" which contains major bugs
that are still present in our release branch 3.3 (and therefore
shouldn't be removed yet).

The new section includes "covariant returns", "two-stage name-lookup"
and "parse errors" which used to be a section of its own. The latter
might not be considered major flaws, but they should be included
because of the given workarounds IMHO.

The "parse errors" section was completely rewritten in order to remove
unnecessary code and to improve readability.
Most other changes are technical details (e.g. a new entry in the table
of contents, anchors, compiler version 3.4.0 instead of 3.4).
 
Tested a valid XHTML 1.0.
Ok to commit?


The patch finishes my rewrite of the bugs/non-bugs part of bugs.html.
If you have further additions/changes for this part, please speak up!
Otherwise, I'll start rewriting the bug reporting part soon.

Regards,
Volker


Index: bugs.html
===================================================================
RCS file: /home/reichelt/GCC/CVS/gcc-cvs/wwwdocs/htdocs/bugs.html,v
retrieving revision 1.81
diff -u -p -r1.81 bugs.html
--- bugs.html	7 Jan 2004 10:30:59 -0000	1.81
+++ bugs.html	12 Jan 2004 20:08:12 -0000
@@ -29,7 +29,7 @@
   <li><a href="#cxx">C++</a>
     <ul>
     <li><a href="#missing">Missing features</a></li>
-    <li><a href="#parsing">Parse errors for "simple" code</a></li>
+    <li><a href="#fixed34">Bugs fixed in the upcoming 3.4.0 release</a></li>
     </ul>
   </li>
   <li><a href="#fortran">Fortran</a></li>
@@ -301,14 +301,9 @@ In particular, bugs caused by invalid co
 <h2><a name="cxx">C++</a></h2>
 
 <h3><a name="missing">Missing features</a></h3>
-<p>We know some things are missing from G++.</p>
 
 <dl>
 
-<dt>Covariant return types</dt>
-<dd><p>Up to (and including) GCC 3.3 we did not implement non-trivial
-covariant returns.  This has been addressed for GCC 3.4.</p></dd>
-
 <dt>The <code>export</code> keyword is not implemented.</dt>
 <dd><p>Most C++ compilers (G++ included) do not yet implement
 <code>export</code>, which is necessary for separate compilation of
@@ -320,83 +315,85 @@ definitions may be included from the hea
 
 </dl>
 
-<h3><a name="parsing">Parse errors for "simple" code</a></h3>
+<h3><a name="fixed34">Bugs fixed in the upcoming 3.4.0 release</a></h3>
+
+<p>The following bugs are present up to (and including) GCC 3.3.x.
+They have been fixed in 3.4.0.</p>
+
+<dl>
+
+<dt>Two-stage name-lookup.</dt>
+
+<dd><p>GCC did not implement two-stage name-lookup (also see
+<a href="#new34">below</a>).</p></dd>
+
+<dt>Covariant return types.</dt>
 
-<p>Up to and including GCC 3.0, the compiler will give "parse error" for
-seemingly simple code, such as</p>
+<dd><p>GCC did not implement non-trivial covariant returns.</p></dd>
 
-<pre>
-struct A{
+<dt>Parse errors for "simple" code.</dt>
+
+<dd><p>GCC gave parse errors for seemingly simple code, such as</p>
+
+<blockquote><pre>
+struct A
+{
   A();
   A(int);
-  void func();
 };
 
-struct B{
+struct B
+{
   B(A);
   B(A,A);
-  void func();
+  void foo();
 };
 
-void foo(){
-  B b(A(),A(1));     //Variable b, initialized with two temporaries
-  B(A(2)).func();    //B temporary, initialized with A temporary
+A bar()
+{
+  B b(A(),A(1));  // Variable b, initialized with two temporaries
+  B(A(2)).foo();  // B temporary, initialized with A temporary
+  return (A());   // return A temporary
 }
-</pre>
+</pre></blockquote>
 
-<p>The problem is that GCC starts to parse the declaration of
-<code>b</code> as a function <code>b</code> returning <code>B</code>,
-taking a function returning <code>A</code> as an argument. When it
-sees the 1, it is too late. The work-around in these cases is to add
-additional parentheses around the expressions that are mistaken as
+<p>Although being valid code, each of the three lines with a comment was
+rejected by GCC.  The work-arounds for older compiler versions proposed
+below do not change the semantics of the programs at all.</p>
+
+<p>The problem in the first case was that GCC started to parse the
+declaration of <code>b</code> as a function called <code>b</code> returning
+<code>B</code>, taking a function returning <code>A</code> as an argument.
+When it encountered the <code>1</code>, it was too late.  To show the
+compiler that this should be really an expression, a comma operator with
+a dummy argument could be used:</p>
+
+<blockquote><pre>
+B b((0,A()),A(1));
+</pre></blockquote>
+
+<p>The work-around for simpler cases like the second one was to add
+additional parentheses around the expressions that were mistaken as
 declarations:</p>
 
-<pre>
-  (B(A(2))).func();
-</pre>
-
-<p>Sometimes, even that is not enough; to show the compiler that this
-should be really an expression, a comma operator with a dummy argument
-can be used:</p>
-
-<pre>
-  B b((0,A()),A(1));
-</pre>
-
-<p>Another example is the parse error for the <code>return</code>
-statement in</p>
-
-<pre>
-struct A{};
-
-struct B{
-  A a;
-  A f1(bool);
-};
+<blockquote><pre>
+(B(A(2))).foo();
+</pre></blockquote>
 
-A B::f1(bool b)
-{
-  if (b)
-    return (A());
-  return a;
-}
-</pre>
+<p>In the third case, however, additional parentheses were causing
+the problems: The compiler interpreted <code>A()</code> as a function
+(taking no arguments, returning <code>A</code>), and <code>(A())</code>
+as a cast lacking an expression to be casted, hence the parse error.
+The work-around was to omit the parentheses:</p>
 
-<p>The problem is that the compiler interprets <code>A()</code> as a
-function (taking no arguments, returning <code>A</code>), and
-<code>(A()</code>) as a cast - with a missing expression, hence the
-parse error. The work-around is to omit the parentheses:</p>
-
-<pre>
-  if (b)
-    return A();
-</pre>
-
-<p>This problem occurs in a number of variants; in <code>throw</code>
-statements, people also frequently put the object in parentheses. The
-exact error also somewhat varies with the compiler version. The
-work-arounds proposed do not change the semantics of the program at
-all; they make them perhaps less readable.</p>
+<blockquote><pre>
+return A();
+</pre></blockquote>
+
+<p>This problem occured in a number of variants; in <code>throw</code>
+statements, people also frequently put the object in parentheses.</p></dd>
+
+</dl>
 
 <hr />
 
@@ -723,7 +720,7 @@ However, some non-conforming constructs 
 option <code>-fpermissive</code> is used.</p>
 
 <p>Two milestones in standard conformance are GCC 3.0 (including a major
-overhaul of the standard library) and the upcoming 3.4 version (with its
+overhaul of the standard library) and the upcoming 3.4.0 version (with its
 new C++ parser).</p>
 
 <h4>New in GCC 3.0</h4>
@@ -774,7 +771,7 @@ decision.</li>
 
 </ul>
 
-<h4>New in GCC 3.4</h4>
+<h4><a name="new34">New in GCC 3.4.0</a></h4>
 
 <p>The new parser brings a lot of improvements, especially concerning
 name-lookup.</p>