Version 4.8, October 18, 2013

This version completes support for all of C++11's "signature" features.  

In particular, the following C++11 features were added since the previous
release:

1) Value categories (N3055)
   C++11 replaces the traditional expression categorization of rvalues vs.
   lvalues by instead distinguishing between lvalues, xvalues, and prvalues.
   Here "xvalue" stands for "eXpiring value" and "prvalue" stands for
   "pure rvalue".  The term "glvalue" stands for "generalized lvalue" (which
   combines the lvalue and xvalue categories), whereas an rvalue is now either
   a prvalue or an xvalue.  The impact of full support for this new
   distinction is relatively small for end-users and IL consumers, but the
   required changes to source files involved in expression processing (expr.c,
   etc.) are substantial.

2) alignas and alignof (N2341)
   The alignment of certain types can now be controlled using the
   "alignas(...)" construct and queried using the "alignof" operator.  (These
   capabilities were previously available through nonstandard attributes and
   operators.)

3) decltype extensions (N3049, N3276)
   The decltype operator can now be used in new contexts: as a name qualifier
   (e.g., "decltype(x)::count"), in destructor calls (e.g.,
   "p->~decltype(x)()"), and as base class names.  Furthermore, the operand of
   a decltype construct can now be a call to a function whose declared return
   type is still incomplete.

4) Inheriting constructors (N2540)
   A new variant of class-scope using-declaration now produces constructors
   and constructor templates in a derived class based on those from a
   designated base class.

5) User-defined literals (N2765)
   Programmers can now use literals with user-defined suffixes that map onto
   calls to a new kind of operator function.

6) thread_local (N2659)
   Variables can now be declared with the "thread_local" specifier to indicate
   that they should be held in thread-local storage.


C++11 also includes resolutions for hundreds of "core issues" that resulted
in language changes that don't rise to the level of a "signature" feature (in
fact, many of these core issues deal with obscure corners of the language).

We continue to implement these resolutions in the front end, and treat their
priority on a case-by-case basis.  Among the various resolutions implemented
as part of this release, two stand out:

-) Opaque enums in class templates (core issue 1206)
   Version 4.5 of the front end introduced support for opaque enumeration
   declarations, but when such a declaration appeared as a member of a class
   template, no syntax was provided to define or specialize such a member
   outside its enclosing class definition.  This support has now been added.

-) Removing the conversion from string literal to char * (core issue 693)
   C++98/C++03 includes a deprecated conversion from string literals to
   (non-const-)char*.  That conversion is no longer part of C++11 and the
   front end now implements that by default in C++11 mode.  A configuration
   macro and a command-line option are available to override the default
   settings.  Also, the front end has been modified to be valid C++11 (this
   missing conversion was the only hindrance to compiling the front end with
   a strict C++11 compiler).

The latest Microsoft and GNU C++ compatibility modes (microsoft_version 1800
and gnu_version 40800, respectively) have also been updated to reflect some
of these new C++11 features.

As usual, we have fixed many other bugs, added many minor features, and
continued to improve our various compatibility modes.  See the Changes_4.8
file for full details (about 3,000 lines).

Despite the number of new features, the overall IL changes for this release
are relatively modest.


Finally, we are considering moving away from the use of separate memory
regions for holding the IL of function definitions.  This is motivated
primarily by the difficulty of implementing new language features within the
constraints of that model.  At the same time, the benefits of separate memory
regions are decreasing because (a) a smaller fraction of the IL consists of
non-inline function bodies, (b) new language features (e.g., C++14 generic
lambdas) will require us to keep some non-inline function bodies in memory
anyway, and (c) development systems are less memory-constrained these days.
As an aid to transitioning to a unified memory model, we are now by default
disabling the early freeing of memory regions associated with function
definitions (which only occurs if an intermediate IL file is used).  The old
behavior can be restored using the FREE_MEMORY_REGIONS_EARLY macro, but we
would like to hear if the new default behavior is problematic for any specific
real-world case.
