llvm-svn: 82430

Add Diagnostic to Indexer, and have it keep its own FileManager instead of taking an external reference (which was leaked in the case of the CIndex library).

llvm-svn: 82429

llvm-svn: 82423

llvm-svn: 82417

 - Does people use this?

llvm-svn: 82406

llvm-svn: 82405

llvm-svn: 82401

is also required for an llvm-side change.

llvm-svn: 82344

Ok, an AssertingVH definitely doesn't work for now because we free our cache after the optimizer may have hacked on the module. Use a WeakVH instead.

llvm-svn: 82324

which will be going away (ie. it's becoming a required parameter) later today.

llvm-svn: 82323

llvm-svn: 82321

 - No functionality change.

llvm-svn: 82320

llvm-svn: 82308

"->", or "::" if we will be looking into a dependent context. It's not
wrong to use the "template" keyword, but it's to needed, either.

llvm-svn: 82307

template smarter, by taking into account which function template
parameters are deducible from the call arguments. For example,

  template<typename RandomAccessIterator>
  void sort(RandomAccessIterator first, RandomAccessIterator last);

will have a code-completion string like

  sort({RandomAccessIterator first}, {RandomAccessIterator last})

since the template argument for its template parameter is
deducible. On the other hand,

  template<class X, class Y>
  X* dyn_cast(Y *Val);

will have a code-completion string like

  dyn_cast<{class X}>({Y *Val})

since the template type parameter X is not deducible from the function
call.

llvm-svn: 82306

angle brackets < > along with placeholder template arguments.

llvm-svn: 82304

r82198 and then reverted. This is an intermediate solution, as diagnostic
caching should not rely on static variables.

llvm-svn: 82301

llvm-svn: 82299

Fix regression introduced by r82198 that caused functions/methods with invalid CFGs to get analyzed.

llvm-svn: 82297

results of code completion, e.g., by providing function call syntax
with placeholders for each of the parameters.

llvm-svn: 82293

llvm-svn: 82292

llvm-svn: 82272

llvm-svn: 82271

llvm-svn: 82265

operators, type specifiers, type names, and nested-name-specifiers.

llvm-svn: 82264

llvm-svn: 82262

Make our char vector types not be explicitly signed to match GCC and to fix compilation with C++ and -fno-lax-vector-conversions

llvm-svn: 82254

llvm-svn: 82253

  - after "using", show anything that can be a nested-name-specifier.
  - after "using namespace", show any visible namespaces or namespace aliases
  - after "namespace", show any namespace definitions in the current scope
  - after "namespace identifier = ", show any visible namespaces or
    namespace aliases

llvm-svn: 82251

llvm-svn: 82250

llvm-svn: 82247

llvm-svn: 82246

llvm-svn: 82234

llvm-svn: 82233

look into the current scope for anything that could start a
nested-names-specifier. These results are ranked worse than any of the
results actually found in the lexical scope.

Perform a little more pruning of the result set, eliminating
constructors, __va_list_tag, and any duplication of declarations in
the result set. For the latter, implemented
NamespaceDecl::getCanonicalDecl.

llvm-svn: 82231

Fix error in _mm_set_pd/_mm_setr_pd and add _mm_set_epi64x/_mm_set1_epi64x. Patch by Laurent Morichetti!

llvm-svn: 82228

results when there is some way to refer to them in the language, such
as with a qualified name in C++.

llvm-svn: 82223

will provide the names of various enumerations currently
visible. Introduced filtering of code-completion results when we build
the result set, so that we can identify just the kinds of declarations
we want.

This implementation is incomplete for C++, since we don't consider
that the token after the tag keyword could start a
nested-name-specifier. 

llvm-svn: 82222

llvm-svn: 82221

expression.

llvm-svn: 82217