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++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.

In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.

Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.

<rdar://problem/11662489> (again)

llvm-svn: 159591

template instantiation. I wasn't able to reproduce this down to
anything small enough to put in our test suite, but it's "obviously"
okay to set the invalid bit earlier and precludes a
known-broken-but-not-marked-broken class from being used elsewhere.

llvm-svn: 159584

attached to a declaration in the completion string.

Since extracting comments isn't free, a new code completion option is
introduced.

A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).

llvm-svn: 159539

This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.

llvm-svn: 159494

keywords when doing type correction.

llvm-svn: 159464

initialized with the next to last element to silence the warning.

llvm-svn: 159458

but apparently I did not.

llvm-svn: 159452

to produce quotes instead of adding qoute to the test.

llvm-svn: 159450

Reviewed by Doug Gregor.

llvm-svn: 159442

No functionality change.

llvm-svn: 159436

value-dependent expression, don't complain that it wasn't the constant
we wanted. Fixes <rdar://problem/11688587> and PR11074.

llvm-svn: 159404

type traits that assignment to/construction of a lifetime-qualified
object under ARC is *not* trivial. Fixes <rdar://problem/11738725>.

llvm-svn: 159401

llvm-svn: 159394

Previously this caused a crash, since protocols are not interfaces.

llvm-svn: 159357

property retains a block object as it could be on 
the stack. // rdar://11761511

llvm-svn: 159293

llvm-svn: 159292

before, so we don't incorrectly think arguments of function type are non-POD.

llvm-svn: 159290

when it appears to be unused and occurs in a header.
// rdar://11202617

llvm-svn: 159282

being updated. Will fix that in a second.

llvm-svn: 159280

llvm-svn: 159279

llvm-svn: 159229

to see if we had an underlying final class or method, but we would then
use the cast type to do the call, resulting in a direct call to the wrong
method.

llvm-svn: 159212

llvm-svn: 159171

This works around a quirk in the way that explicit template specializations are
handled in Clang. We generate an implicit declaration from the original
template which the explicit specialization is considered to redeclare. This
trips up the explicit delete logic.

This change only works around that strange representation. At some point it'd
be nice to remove those extra declarations to make the AST more accurately
reflect the C++ semantics.

Review by Doug Gregor.

llvm-svn: 159167

resulted in it being reverted. A test for that bug was added in r158950.

Original comment:

If an object (such as a std::string) with an appropriate c_str() member function
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: 159159

for non-type template parameters in microsoft mode.
PR12709.

llvm-svn: 159147

id <Protocol>. // rdar://11618852

llvm-svn: 159084

This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:

  __thread int x __attribute__((tls_model("initial-exec")));

if it will not be used in a shared library that is dlopen'ed.

This depends on LLVM r159077.

llvm-svn: 159078

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

llvm-svn: 159046

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

llvm-svn: 158965

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

This reverts commit 7d96f6106bfbd85b1af06f34fdbf2834aad0e47e.

llvm-svn: 158949

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

llvm-svn: 158938

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