llvm-svn: 82526

llvm-svn: 82525

Fix: <rdar://problem/7242015> [RegionStore] variable passed-by-reference (via integer) to function call not invalidated

llvm-svn: 82523

 - Switching all of them out-of-my-current-scope-of-interest, sorry.

llvm-svn: 82515

llvm-svn: 82514

llvm-svn: 82513

llvm-svn: 82512

llvm-svn: 82511

llvm-svn: 82508

llvm-svn: 82502

Several of the existing methods were identical to their respective
specializations, and so have been removed entirely.  Several more 'leaf'
optimizations were introduced.

The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.

llvm-svn: 82501

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: 82481

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: 82435

llvm-svn: 82433

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

llvm-svn: 82431

llvm-svn: 82430

llvm-svn: 82423

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

"->", 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: 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