Also, add a few random extra open projects.

Most of C++ support is done; we don't need the status page anymore. We're
hoping that the C++-related open projects are the only major pieces of
functionality we don't model at this point.

llvm-svn: 179659

llvm-svn: 179658

llvm-svn: 179631

This is no longer true.

llvm-svn: 179519

llvm-svn: 179490

constructor. This isn't quite perfect (as usual, we don't handle default
arguments correctly yet, and we don't deal with copy/move constructors for
arguments correctly either, but this will be fixed when we implement core issue
1351.

This completes our support for inheriting constructors.

llvm-svn: 179154

llvm-svn: 179055

In the comparison, both clang and GCC are popular and widely adopted.  This is no longer a win of GCC.

This whole doc should really be looked at.

llvm-svn: 179040

llvm-svn: 177325

any, and add a note that we cannot treat __int128 as an extended integral type.

llvm-svn: 177324

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

llvm-svn: 176515

See http://clang-analyzer.llvm.org/release_notes.html for what's new
in this build.

llvm-svn: 176389

Reword the FAQ to stress more that the assert should be used only in case
the developer is sure that the issue is a false positive.

llvm-svn: 176335

llvm-svn: 176221

llvm-svn: 176211

 * 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

llvm-svn: 175090

llvm-svn: 174942

+ added progress information for several checkers

llvm-svn: 174941

llvm-svn: 174918

llvm-svn: 174759

llvm-svn: 174758

Turns out we didn't update scan-build to work with HTML files in nested directories.

llvm-svn: 174256

llvm-svn: 174252

llvm-svn: 174126

 * 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

llvm-svn: 171885

llvm-svn: 171870

llvm-svn: 171823

llvm-svn: 171560

Suggested by Sean McBride, thanks!

llvm-svn: 168745

Suggested by Sean McBride, thanks!

llvm-svn: 168744

llvm-svn: 168118

llvm-svn: 168015

Patch by Sean McBride!

llvm-svn: 167537

llvm-svn: 167098

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

llvm-svn: 165705