implement correct functionality, even if it's not optimal. On this basis, mark
"data dependency ordering" as done. Add footnotes for cases where our
implementation is known to be suboptimal.

llvm-svn: 176891

llvm-svn: 176781

 * Mark attributes as done in SVN.
 * Downgrade alignment support from 'Clang 3.0' to 'SVN', now that we actually implement the rules.
 * Upgrade 'Dynamic initialization with concurrency' from 'No' to 'Clang 2.9' -- all that is required here is the ABI-mandated locking for the initialization of static locals.

llvm-svn: 175882

 * Mark 'sequence points' as done now we have a warning for unsequenced operations
 * Mark 'memory model' as done now we correctly model bitfield operations

llvm-svn: 173771

libraries have an incorrect definition of std::common_type (inherited from a
bug in the standard -- see LWG issue 2141), whereby they produce reference
types when they should not.

If we instantiate a typedef named std::common_type<...>::type, which is defined
in a system header as decltype(... ? ... : ...), and the decltype produces a
reference type, convert it to the non-reference type. (This doesn't affect any
LWG2141-conforming implementation of common_type, such as libc++'s, because the
default implementation of common_type<...>::type isn't supposed to produce a
reference type.)

This is horrible. I'm really sorry. :( Better ideas appreciated!

llvm-svn: 166455

Clang can now cope with its eccentricities in C++11 mode.

llvm-svn: 165265

llvm-svn: 157308

Color is still yellow, as 3.1 isn't released yet.

llvm-svn: 155217

we generate correct code for both strong and weak atomic compare-exchanges, even
though we don't propagate to the IR enough information to generate optimal weak
compare-exchanges on architectures which support them.

llvm-svn: 155161

from the C++ status page.

llvm-svn: 154890

implementations, mark the atomics-related parts of the C++11 status page
as done. I've not marked 'Strong Compare and Exchange' done, since although
we implement supporting builtins, we don't yet produce different code for
the weak and strong forms.

llvm-svn: 154644

return types, from Michel Morin!

llvm-svn: 154428

between unscoped enumerations and class template member specializations,
whose behavior is currently under discussion in CWG (and for which there
is a preference to not implement the currently-standardized wording).

llvm-svn: 153464

forward-declared enums aren't /quite/ done yet.

llvm-svn: 153350

a previous declaration if the redeclaration is invalid. That way lies madness.
Fixes a crash-on-invalid reported by Abramo.

llvm-svn: 153349

scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.

llvm-svn: 152750

collection'. Keep it in the table to match gcc's table, but mark it N/A.

llvm-svn: 152528

basic source character set in C++98. Add -Wc++98-compat diagnostics for same in
literals in C++11. Extend such support to cover string literals as well as
character literals, and mark N2170 as done.

This seems too minor to warrant a release note to me. Let me know if you disagree.

llvm-svn: 152444

llvm-svn: 152396

llvm-svn: 151992

llvm-svn: 151458

"C++0x". Use "C++98" to refer to C++98, not "C++". Add heading for C++98
support section.

llvm-svn: 151381

agreed on IRC, any remaining issues are best dealt with as bugs.

We have no __has_feature check for this; please shout if you'd like one. This
feature seems too small to be worth its own release notes bullet (again, please
shout if you disagree).

llvm-svn: 151380

  - Apparently, SVN is yellow
  - Note that initializer lists are "in progress"

llvm-svn: 151232

llvm-svn: 151231

features. :)

llvm-svn: 150522

llvm-svn: 148021

in a constant expression, for compatibility with g++.

llvm-svn: 148020

llvm-svn: 143803

llvm-svn: 143539

llvm-svn: 143535

3.0. Fixses PR11252.

llvm-svn: 143216

Tweak the C++11 status prose a bit. We still need better user guidance on the standard library issue

llvm-svn: 142019

user-centric list, with Clang version numbers, following GCC's lead
(and user requests).

llvm-svn: 142015

llvm-svn: 141949

Now that we support move generation, mention this in the language extension and C++ status pages. Also update the C++ status for default functions, which are complete now that we can generate move functions, and destructor exception specifications, which I did a while ago.

llvm-svn: 141558

llvm-svn: 137299

Update C++0x status page to reflect support for unicode string and character literals, from Craig Topper

llvm-svn: 136216

conversion operators, from Jonathan Sauer.

llvm-svn: 135932

llvm-svn: 135689