- 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

  - 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

expression.

llvm-svn: 82217

llvm-svn: 82213

llvm-svn: 82212

llvm-svn: 82211

llvm-svn: 82210

llvm-svn: 82209

llvm-svn: 82208

when running the analyzer on real projects.  We'll keep the change to
AnalysisManager.cpp in r82198 so that -fobjc-gc analyzes code
correctly in both GC and non-GC modes, although this may emit two
diagnostics for each bug in some cases (a better solution will come
later).

llvm-svn: 82201

pruning of diagnostics that may be emitted multiple times.  This is
accomplished by adding FoldingSet profiling support to PathDiagnostic,
and then having BugReporter record what diagnostics have been issued.

This was motived to a serious bug introduced by moving the
'divide-by-zero' checking outside of GRExprEngine into a separate
'Checker' class.  When analyzing code using the '-fobjc-gc' option, a
given function would be analyzed twice, but the second time various
"internal checks" would be disabled to avoid emitting multiple
diagnostics (e.g., "null dereference") for the same issue.  The
problem is that such checks also effect path pruning and don't just
emit diagnostics.  This resulted in an assertion failure involving a
real divide-by-zero in some analyzed code where we would get an
assertion failure in APInt because the 'DivZero' check was disabled
and didn't prune the logic that resulted in the divide-by-zero in the
analyzer.

The implemented solution is somewhat of a hack, and may not perform
extremely well.  This will need to be cleaned up over time.

As a regression test, 'misc-ps.m' has been modified so that its tests
are run using -fobjc-gc to test this diagnostic pruning behavior.

llvm-svn: 82198

with zeros.  This avoids a GCC warning (PR5000)

llvm-svn: 82194

llvm-svn: 82193