llvm-svn: 82495

gcc-style write-barrier api only.

llvm-svn: 82493

integer pointer.  For now just invalidate the fields of the struct.

This addresses: <rdar://problem/7185607> [RegionStore] support invalidation of bit fields using integer assignment

llvm-svn: 82492

llvm-svn: 82482

llvm-svn: 82481

llvm-svn: 82478

a nested-name-specifier that describes how to refer to that name. For
example, given:

  struct Base { int member; };
  struct Derived : Base { int member; };

the code-completion result for a member access into "Derived" will
provide both "member" to refer to Derived::member (no qualification needed) and
"Base::member" to refer to Base::member (qualification included).

llvm-svn: 82476

enumerators when either the user intentionally wrote a qualified name
(in which case we just use that nested-name-specifier to match
the user's code) or when this is the first "case" statement and we
need a qualified name to refer to an enumerator in a different scope.

llvm-svn: 82474

llvm-svn: 82472

of enumeration type, providing the various unused enumerators as options.

llvm-svn: 82467

real work is performed within Sema. Addresses Chris's comments, but
still retains the heavyweight list-of-multimaps data structure.

llvm-svn: 82459

llvm-svn: 82437

llvm-svn: 82435

llvm-svn: 82433

 - Currently this requires us to fake an input file.

 - This allows Sema to be keep all the logic for how to pull decls out of the external AST source and how to handle things like tentative definitions.

llvm-svn: 82432

 - It isn't really clear what to do with the preprocessor here, but this is more sensible.

llvm-svn: 82431

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