essence, code completion is triggered by a magic "code completion"
token produced by the lexer [*], which the parser recognizes at
certain points in the grammar. The parser then calls into the Action
object with the appropriate CodeCompletionXXX action.

Sema implements the CodeCompletionXXX callbacks by performing minimal
translation, then forwarding them to a CodeCompletionConsumer
subclass, which uses the results of semantic analysis to provide
code-completion results. At present, only a single, "printing" code
completion consumer is available, for regression testing and
debugging. However, the design is meant to permit other
code-completion consumers.

This initial commit contains two code-completion actions: one for
member access, e.g., "x." or "p->", and one for
nested-name-specifiers, e.g., "std::". More code-completion actions
will follow, along with improved gathering of code-completion results
for the various contexts.

[*] In the current -code-completion-dump testing/debugging mode, the
file is truncated at the completion point and EOF is translated into
"code completion".

llvm-svn: 82166

llvm-svn: 82164

 - Move CMake to using the new test runner.

 - Switch Makefiles to use the lit.site.cfg.in template.

 - Remove explicit --path arguments, instead this gets written into the site
   configuration. This means running lit from the command line should use the
   exact same configuration as is used in 'make test', assuming it can find the
   site configuration file. You still need to run 'make test' (or the cmake
   build target equivalent) at least once.

llvm-svn: 82160

complain about specializations of member functions that are not
definitions. Fixes PR4995.

llvm-svn: 82159

llvm-svn: 82154

 - Based on patch by Shantonu.

llvm-svn: 82147

llvm-svn: 82146

llvm-svn: 82133

 - Patch by Shantonu Sen!

<rdar://problem/6922650> clang doesn't know about ARM registers for inline asm clobber lists

llvm-svn: 82132

llvm-svn: 82131

 - Doug, please check.

 - PR4940.

llvm-svn: 82129

llvm-svn: 82128

llvm-svn: 82126

llvm-svn: 82125

llvm-svn: 82124

llvm-svn: 82123

llvm-svn: 82122

llvm-svn: 82121

already preprocessed.

--
ddunbar@giles:tmp$ touch t.i
ddunbar@giles:tmp$ gcc -E t.i
ddunbar@giles:tmp$ clang -E t.i
clang: warning: t.i: previously preprocessed input unused when '-E' is present
ddunbar@giles:tmp$ 
--

<rdar://problem/6813375> [driver] driver prints confusing message when running -E on preprocessed file

llvm-svn: 82120

llvm-svn: 82119

This fixes some bad -O0 codegen and the unnecessary clearing of al on entry to objc_msgSend for most message sends.

<rdar://problem/7102824> [irgen] unnecessary xorb on calls to objc_msgSend on x86_64

llvm-svn: 82118

llvm-svn: 82117

llvm-svn: 82116

llvm-svn: 82115

When mangling function template specialization, mangle the type encoding of the original function template. Also, port mangle.cpp and function-template-specialization.cpp over to using FileCheck.

llvm-svn: 82114

llvm-svn: 82113

PCH: When writing PCH files, tweak the predicate function deciding whether to mark a decl as "external" to be closer to reality. 

This still isn't perfect, but I believe it is conservatively accurate at marking decls which IRgen needs to see, while still keeping the "deserialization footprint" on Cocoa.h.

llvm-svn: 82112

PCH: When deserializing an explicit "external definition", don't pass it to HandleTopLevelDecl -- this is already being done inside the reader.

This is something of a hack, since whether the reader actually did this depends on the "isConsumerInterestedIn" predicate. I think we need to rework how this works, but I need to discuss with Doug.

llvm-svn: 82111

 - Doesn't actually work yet because only module level asm's get correctly marked as externally visible in the PCH.

 - Other things like 'clang-cc foo.ast -ast-dump' now work, as well.

llvm-svn: 82107

llvm-svn: 82106

llvm-svn: 82105

llvm-svn: 82104

llvm-svn: 82103

llvm-svn: 82102

llvm-svn: 82101

llvm-svn: 82099

llvm-svn: 82098

llvm-svn: 82096

llvm-svn: 82095

llvm-svn: 82094