🚀 go-pugleaf

In article <1jk51qINNj8j@fido.asd.sgi.com> asgeir@viking.asd.sgi.com (Asgeir Eiriksson) writes:

   Is there a way to access the bug list for a particular release?

I'm afraid not.

   How about the list of bugs that are fixed in a particular release?

Well, here's a list of some of the different things that were changed
between 2.2.2 and 2.3.3 (approximately).

--
* Handling @code{const} and @code{volatile} references is improved when
they are used as arguments.  When passing a non-const argument into a
function expecting a @code{const} reference, the compiler will make an effort
to match a function accepting a non-const reference first.

* The implicit @code{this} parameter to class functions is no longer
considered in the cost for matching possible function candidates.  Among
other things, the argument could be point to a derived class, which
would make the choice more expensive.

* For a class that has only private member functions, the compiler will
also provide the name of the class when generating warnings.

* In accordance with ARM section 9.4, the compiler will not permit fields
of local classes to be declared @code{static}.

* The compiler will more intelligently deal with @code{extern "C"} functions
being made friends.

* Use of user-defined conversion operators is now checked more strictly
for possibly ambiguities.

* The option @samp{-Wredundant-decls} will warn about multiple redundant
declarations for the same variable or function.

* Support for nested enumerated types has been improved, particularly in
situations where the types are actually located in base classes.

* Wrappers are no longer supported in the compiler; this helped, in part,
to achieve a 12% code reduction in the compiler.

* The compiler's performance has been tweaked in a few areas; the second
phase will include a full profiling and analysis of the C++ front-end. 

* Member functions can be called without objects if the functions are
declared to be @code{static}.

* When attempting to convert from one type to another, the compiler will
provide the user with @emph{both} types involved in the error message,
rather than just vaguely say that something couldn't be converted to a
reference type.  Also, if a method's name is duplicated in a class, the
compiler will give you both the class and the function to aid in
debugging.  (No more ``aggregate scope'' error messages.)

* Finding members of nested classes, and diagnosing possible access
violations, are more properly performed.

* Handling severe compiler errors was completely changed.  Now even in the
most disastrous cases, the compiler will no longer core dump with an
abort, or die with a segmentation fault.  Instead, it will notify the
user of the internal compiler error, and encourage submission of a bug
report.  In most cases, the compiler will also provide an internal
reference number, which will aid the maintainers in diagnosing the
problem.

* The math functions @code{sin} and @code{cos} have built-in equivalents,
to match the C front-end.

* The wide character type @samp{wchar_t} has been added as a recognized
type, per the specification in the ANSI X3J16 standards working paper.

* To comply with ARM section 9.5, the compiler will not allow anonymous
unions to have function members.

* Initialization of references has been greatly refined, fully
implementing section 9.4 of the ARM.

* According to section 7.1 of the ARM, a @code{const} object does not have
external linkage and must be initialized, unless it is explicitly
declared extern.  GNU C++ now follows this dictum, but this behavior may
be slightly changed in the second phase, to allow cases where such
constructs are common practice.  

* The compiler will reject attempts to declare type conversion operators
as non-member functions.

* Section 12.1 of the ARM says that neither constructors nor destructors
may not be declared to be @code{const} or @code{volatile}, and may not
be @code{static}.  GNU C++ will now correctly diagnose these cases.  In
addition, constructors will not be allowed to be declared to be @code{virtual}.

* To comply with ARM section 9.5, an error will be generated if a union is
declared to have virtual functions.

* Member initialization has been changed with the first phase of Reno.  By
default, no member in a class definition may be initialized.  Static
members will not be permitted to be initialized, since they must be
defined separately from their declaration.  In the interests of
backwards compatibility, @code{const} members will be allowed to have
initializers, unless the @samp{-pedantic} flag is used.  GNU C++ is
closer to compliance with section 9.2.2 of the ANSI C++ working paper,
but will probably never be an exact match.

* The function @samp{main} will not be allowed to be declared to have
@code{static} linkage.

* The @samp{extern inline} extension of GNU C and C++ will be warned
against with the @samp{-ansi} flag, and produce an error with
@samp{-pedantic}.

* To agree with ARM section 8.2, GNU C++ will not allow local variables to
be used in default argument expressions.

* Protected base classes are implemented and supported.

* Ambiguity checking and better support for multiple inheritance was
greatly improved.

* Debugging info for enumeral types is now emitted in many more cases than
before.

* Scoping rules for @code{friend} functions have been corrected to make them be
in the same lexical scope as the scope of the class in which it is
defined.

* The @samp{-Wchar-subscripts} flag will warn when arrays are referenced
with subscripts of type @samp{char}, which on some systems could be
signed, leading to unexpected results.

* The options @samp{+e0} and @samp{+e1}, which provide some
call-compatibility with other C++ compilers, are now recognized and
handled correctly.

* The compiler will now more intelligently recognize ambiguities between
conversion operators and constructors.

* When used with the @code{-traditional} flag, the sequences @samp{\x} and
@samp{\a} will resolve to just @samp{x} and @samp{a}, respectively.  If
used with @samp{-Wtraditional}, a warning about this difference in
behavior will be generated.

* The compiler will now recognize @samp{\e} in addition to @samp{\E} for
an escape sequence, but will warn about its non-compliance with the
emerging ANSI standard if @samp{-pedantic} is used.

* Bugs in the handling of multi-byte strings (of the form @samp{L"..."})
have been corrected.

* The compiler previously made mistakes with how to handle the context of
a virtual function; it now behaves much better.

* Working with nested types in template classes has been improved to a
degree; the second phase of Reno will include many improvements to the
compiler's handling of templates in general.

* The GNU C front-end extension of using labels as values
(@samp{&&@var{label}}) and its accompanying support of the computed goto
(@samp{goto *@var{exp}}) has been added to the C++ front-end.

* Neither operator @code{new} nor operator @code{delete} may now be
declared as @samp{virtual}.

* Attempts to overload operator @code{delete} is more strictly controlled,
per section 12.5 of the ARM.

* Operator @code{delete} now behaves properly when used with non-pointers,
constant pointers, and pointers with the value 0.

* It is now illegal to apply operator @code{new} to a reference type.

* Using operator @code{new} with placement has been dramatically improved.

* The compiler will now warn that use of operator @code{new} with the old
placement syntax (using curly braces, as in @samp{new @{@var{foo}@}})
should be replaced by using proper syntax (@samp{new (@var{foo})}).

* Casts to references are now allowed to be used as lvalues, per ARM
section 5.4.

* According to ARM section 8.4.2, it is illegal to initialize a character
array with more initializers than there are array elements.  In C, it's
legal to forget about the terminating @samp{\0}, but in C++ it's now an
error if the array's initialization does not fit, @emph{including} the
trailing null character.

* An array reference is now considered @code{const} or @code{volatile} if
the array elements are or if the array itself is.
--
--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Mountain View, CA                              +1 415 903 1400