attributes in more places where we didn't and catching a lot more issues.

This implements nearly every aspect of C++11 attribute parsing, except for:
 - Attributes are permitted on explicit instantiations inside the declarator
   (but not preceding the decl-spec)
 - Attributes are permitted on friend declarations of functions.
 - Multiple instances of the same attribute in an attribute-list (e.g.
   [[noreturn, noreturn]], not [[noreturn]] [[noreturn]] which is conforming)
   are allowed.
The first two are marked as expected-FIXME in the test file and the latter
is probably a defect and is currently untested.

Thanks to Richard Smith for providing the lion's share of the testcases.

llvm-svn: 159072

Heavily based on a patch from
Aaron Wishnick <aaron.s.wishnick@gmail.com>.

I'll clean up the duplicated function in CodeGen as
a follow-up, later today or tomorrow.

llvm-svn: 159060

[Windows] Fix mangling of repeated types in the presence of bool and function pointers PR13176,PR13177

llvm-svn: 159059

MicrosoftMangle: Fix mangling of integral constant non-type template arguments in a class specialization.

llvm-svn: 159056

llvm-svn: 159054

llvm-svn: 159047

llvm-svn: 159046

relinquish memory.

llvm-svn: 159043

(Committed in r159038 by mistake.)

llvm-svn: 159040

This would be useful to investigate performance issues.

llvm-svn: 159038

llvm-svn: 159037

llvm-svn: 159036

revert CodeGen support for the alloc_size attribute until we finish the design of a more generic metadata node

llvm-svn: 159016

We don't handle exceptions yet, so we treat them as sinks. ExprEngine
hardcodes messages that are known to raise Objective-C exceptions like -raise,
but it was only checking for +raise:format: and +raise:format:arguments: on
NSException itself, not subclasses.

<rdar://problem/11724201>

llvm-svn: 159010

properly if there is a join point in the control flow graph that involves
a trylock.  Also changes the source locations of some warnings to be
more consistent.

llvm-svn: 159008

when the calling site is a member function template.

Effectively reverts r111675.

llvm-svn: 159004

llvm-svn: 159001

llvm-svn: 158985

llvm-svn: 158982

llvm-svn: 158981

* Primarily fixed \param commands with names not matching any actual
  parameters of the documented functions.  In many cases this consists
  just of fixing up the parameter name in the \param to match the code,
  in some it means deleting obsolete documentation and occasionally it
  means documenting the parameter that has replaced the older one that
  was documented, which sometimes means some simple reverse-engineering
  of the docs from the implementation;
* Fixed \param ParamName [out] to the correct format with [out] before
  the parameter name;
* Fixed some \brief summaries.

llvm-svn: 158980

* Add \brief summaries;
* Escape # characters in Doxygen comments;
* Add \code...\endcode markup for code examples;
* Add \verbatim...\endverbatim markup for grammar productions.

llvm-svn: 158976

llvm-svn: 158974

* Use \p param for a parameter reference, not the (erroneous) form \arg param;
* Escape # characters in Doxygen comments as needed.

llvm-svn: 158971

llvm-svn: 158970

llvm-svn: 158968

llvm-svn: 158965

transfered with dataWithBytesNoCopy.

llvm-svn: 158958

Revert "If an object (such as a std::string) with an appropriate c_str() member function"

This reverts commit 7d96f6106bfbd85b1af06f34fdbf2834aad0e47e.

llvm-svn: 158949

Handle include directive with comments.  It turns out that in this case comments are not coming in source order.  Instead of trying to std::sort() comments (which can be costly), just remove comments that are not in order.

llvm-svn: 158940

then it should get the same warnings that id->isa gets. // rdar://11702488

llvm-svn: 158938

llvm-svn: 158936

This now correctly covers, I believe, all the pointer types:
* 'any' pointers (both function and data normal pointers and ObjC object pointers)
* member pointers (both function and data)
* block pointers

llvm-svn: 158931

method declarations.
// rdar://11578353.

llvm-svn: 158929

TargetSimulatroVersionFromDefines if present;  this also makes
it easier to chain things correctly.  Noted by an internal
review.

llvm-svn: 158926

1. Accept flags -g[0-3], -ggdb[0-3], -gdwarf-[2-4] and collapse them to simple -g (except -g0/-ggdb0).
2. Produce driver error on unsupported formats (-gcoff, -gstabs, -gvms) and options (-gtoggle).
3. Recognize and ignore flags -g[no-]strict-dwarf, -g[no-]record-gcc-switches.

llvm-svn: 158906

In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) This leads to
odd warnings when returning enum constants directly in blocks with inferred
return types. The easiest way out of this is to pretend that, like C++, enum
constants have enum type when being returned from a block.

<rdar://problem/11662489>

llvm-svn: 158899

Also, don't warn if the used function is __attribute__((const)), in which case
it's not supposed to use global variables anyway.

The inline-in-inline thing is a heuristic, and one that's possibly incorrect
fairly often because the function being inlined could definitely use global
variables. However, even some C standard library functions are written using
other (trivial) static-inline functions in the headers, and we definitely don't
want to be warning on that (or on anything that /uses/ these trivial inline
functions). So we're using "inlined" as a marker for "fairly trivial".

(Note that __attribute__((pure)) does /not/ guarantee safety like ((const),
because ((const)) does not guarantee that global variables are not being used,
and the warning is about globals not being shared across TUs.)

llvm-svn: 158898

appropriate. Patch by João Matos!

llvm-svn: 158895

express library-level dependencies within Clang.

This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.

llvm-svn: 158888