<tr1/hashtable> header, where a friend class template
std::tr1::__detail::_Map_base is declared with the wrong template
parameters. GCC doesn't catch the problem, so Clang does a little
back-flip to avoid diagnosing just this one instance of the problem.

llvm-svn: 100790

Declarator that depends on it.  This fixes several redundant errors and bad
recoveries.

llvm-svn: 100779

llvm-svn: 100753

llvm-svn: 100750

Fronted: Kill overly specialized RecordLayoutDumper, just make -dump-record-layouts a bit that Sema honors.

llvm-svn: 100747

methods. wip.

llvm-svn: 100734

llvm-svn: 100732

llvm-svn: 100730

parameter, explicitly ask the user to give it arguments.  We used to
complain that it wasn't a type and expect the user to figure it out.

llvm-svn: 100729

isNotEmpty calls.

llvm-svn: 100722

code won't actually get used yet because we don't handle non-type
parameter packs, but when we do, this code should jump in and work.

llvm-svn: 100716

llvm-svn: 100707

llvm-svn: 100704

isn't any extra work to perform. Also, don't check for unused
parameters when the warnings will be suppressed anyway. Improves
performance of -fsyntax-only on 403.gcc's combine.c by ~2.5%. 
<rdar://problem/7836787>

llvm-svn: 100686

  - When instantiating a friend type template, perform semantic
  analysis on the resulting type.
  - Downgrade the errors concerning friend type declarations that do
  not refer to classes to ExtWarns in C++98/03. C++0x allows
  practically any type to be befriended, and ignores the friend
  declaration if the type is not a class.

llvm-svn: 100635

semantic analysis) and Sema::ActOnFriendTypeDecl (the action
callback). This is a prerequisite for improving template instantiation
of friend type declarations.

llvm-svn: 100633

Fixes a spurious warning in LLVM.

llvm-svn: 100595

have a temporary object in C++.

Also fix a tag mismatch that Doug noticed.

llvm-svn: 100593

definitions, e.g., after 

  -

or

  - (id)

we'll find all of the "likely" instance methods that one would want to
declare or define at this point. In the latter case, we only produce
results whose return types match "id".

llvm-svn: 100587

llvm-svn: 100583

Fixes radar 7823675.

llvm-svn: 100582

declared in categories.

llvm-svn: 100577

  (void*) someFunction(5, 10, 15, 20);
where the cast is presumably meant to be to 'void'.

llvm-svn: 100574

that protected members be used on objects of types which derive from the
naming class of the lookup.  My first N attempts at this were poorly-founded,
largely because the standard is very badly worded here.

llvm-svn: 100562

while we're completing in the middle of a function call), also produce
"ordinary" name results that show what can be typed at that point.

llvm-svn: 100558

llvm-svn: 100557

statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".

llvm-svn: 100555

down the set of code-completion results based on Objective-C
conventions. 

llvm-svn: 100548

presence of precompiled headers by forcibly loading all of the
methods we know about from the PCH file before constructing our
code-completion list.

llvm-svn: 100535

"id" or an expression of type "id". In these cases, we produce a list
of all of the (class or instance) methods, respectively, that we know about.

Note that this implementation does not yet work well with precompiled
headers; that's coming soon.

llvm-svn: 100528

llvm-svn: 100496

Fix possible null dereference by bailing out of CheckObjCPropertyAttributes() early if the Decl* is null.

llvm-svn: 100483

of file locations for anonymous tag types (e.g., "enum <anonymous at
t.h:15:6>"), which can get rather long.

llvm-svn: 100470

of macro definitions when passed to CIndex. Add test for code
completion of macros via CIndex.

llvm-svn: 100431

(radar 7822210).

llvm-svn: 100226

property is being accessed without the dot-syntax notation.
(radar 7822344).

llvm-svn: 100212

llvm-svn: 100210

llvm-svn: 100197

poor (and wrong) approximation of the actual rules governing when to
build a copy and when it can be elided.

The correct implementation is actually simpler than the
approximation. When we only enumerate constructors as part of
initialization (e.g., for direct initialization or when we're copying
from a class type or one of its derived classes), we don't create a
copy. When we enumerate all conversion functions, we do create a
copy. Before, we created some extra copies and missed some
others. The new test copy-initialization.cpp shows a case where we
missed creating a (required, non-elidable) copy as part of a
user-defined conversion, which resulted in a miscompile. This commit
also fixes PR6757, where the missing copy made us reject well-formed
code in the ternary operator.

This commit also cleans up our handling of copy elision in the case
where we create an extra copy of a temporary object, which became
necessary now that we produce the right copies. The code that seeks to
find the temporary object being copied has moved into
Expr::getTemporaryObject(); it used to have two different
not-quite-the-same implementations, one in Sema and one in CodeGen.

Note that we still do not attempt to perform the named return value
optimization, so we miss copy elisions for return values and throw
expressions.

llvm-svn: 100196

If a constructor is a dependent context, just set the base and member initializers as they are written. Fixes a bug where we wouldn't show initialization order warnings when instantiating.

llvm-svn: 100180