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

is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.

Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.

Patch by Sam Panzer!

llvm-svn: 158887

is permitted by all relevant language standards. Patch by Andy Gibbs!

llvm-svn: 158883

RawCommentList::addComment: fix the assertion so it actually checks that new comment is after the last one (change Comments[0] to Comments.back()), and handle the case of two consecutive comments, e.g. /** *//* */.  There is already a testcase for that (but it didn't trigger the assert because the assert itself was wrong).

llvm-svn: 158882

llvm-svn: 158875

has not overridden the property. // rdar://11656982

llvm-svn: 158871

"write" attribute (copy/retain/etc.). But, property declaration in 
primary class and protcols are tentative as they may be overridden 
into a 'readwrite' property in class extensions. Postpone diagnosing 
such warnings until the class implementation is seen. 
// rdar://11656982

llvm-svn: 158869

places.  I've turned this off for the GNU runtimes --- I don't know if
they support weak class import, but it's easy enough for them to opt in.

Also tweak a comment per review by Jordan.

llvm-svn: 158860

This commits sets the grounds for more aggressive use after free
checking. We will use the Relinquished sate to denote that someone
else is now responsible for releasing the memory.

llvm-svn: 158850

Remove unused ASTContext& arg in RawCommentList::addComment, as pointed out by Chandler in commit message for r158807.

llvm-svn: 158845

in microsoft mode. Fixes PR12701.

The code for this was already in 2 of the 3 branches of a
conditional and missing in the 3rd branch, so lift it above
the conditional.

llvm-svn: 158842

llvm-svn: 158837

It's very easy for anonymous external linkage to propagate in C++ through
return types and parameter types. Likewise, it's possible that a template
containing an inline function is only used with parameters that have internal
linkage. Actually diagnosing where the internal linkage comes from is fairly
difficult (both to locate and then to print nicely). Finally, since we only
have one translation unit available, we can't even prove that any of this
violates the ODR.

This warning needs better-defined behavior in C++ before it can really go in.

Rewording of the C warning (which /is/ specified by C99) coming shortly.

llvm-svn: 158836

error was asserting on anything that included Windows.h.  MS-style inline asm is
still dropped, but at least now we're not completely silent about it.

llvm-svn: 158833

CreateEnumType doesn't participate in caching so the descriptor for the enum
gets recomputed for every reference of an element of an enum, only to get
discarded when it gets turned into an MDNode.

No functionality change except performance.

llvm-svn: 158832

llvm-svn: 158830

change in behavior. // rdar://11671080

llvm-svn: 158828

That commit added a new library just to hold the RawCommentList. I've
started a discussion on the commit thread about whether that is really
meritted -- it certainly doesn't seem necessary at this stage.

However, the immediate problem is that the AST library has a hard
dependency on the Comment library, but the dependencies were set up
completely backward. In addition to the layering violation, this had an
unfortunate effect if scattering the Comments library dependency
throughout the build system, but inconsistently so -- several parts of
the CMake dependencies were missing and only showed up due to transitive
deps or the fact that the target wasn't being built by tho bots.

It turns out that the Comments library can't (currently) be a well
formed layer *below* the AST library either, as it has an API that
accepts an ASTContext. That parameter is currently unused, so maybe that
was a mistake?

Anyways, it really seems like this is logically part of the AST --
that's the whole point of the ASTContext providing access to it as far
as I can tell -- so I've merged it into the AST library to solve the
immediate layering violation problems and remove some of the churn from
our library dependencies.

llvm-svn: 158807