dereferencing it, except for this one section of code.  Add a null
check around it.
clang static analyzer fix.

llvm-svn: 219920

Before:
  return (a)[foo bar : baz];

After:
  return (a)[foo bar:baz];

llvm-svn: 219919

clang unreachable code warning.

llvm-svn: 219918

llvm-svn: 219917

clang unreachable code warning.

llvm-svn: 219916

llvm-svn: 219915

llvm-svn: 219914

llvm-svn: 219913

llvm-svn: 219912

llvm-svn: 219911

a number of warnings to be enabled.  The one making the most noise
across the code base right now is CLANG_WARN_UNREACHABLE_CODE = YES.

llvm-svn: 219910

clang static analyzer fixit.

llvm-svn: 219909

clang static analyzer fixit.

llvm-svn: 219908

clang static analyzer fixit.

llvm-svn: 219907

llvm-svn: 219906

clang static analyzer fixit.

llvm-svn: 219905

clang static analyzer fixit.

llvm-svn: 219904

llvm-svn: 219903

The code committed in r219832 asserted when it attempted to shrink a switch
statement whose type was larger than 64-bit.

llvm-svn: 219902

llvm-svn: 219901

PR21246: DebugInfo: Emit the appropriate type (cv qualifiers, reference-ness, etc) for non-type template parameters

Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.

Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.

(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)

llvm-svn: 219900

Make tail recursion elimination a bit more aggressive.  This allows us to get
tail recursion on functions that are just branches to a different function.  The
fact that the function takes a byval argument does not restrict it from being
optimised into just a tail call.

llvm-svn: 219899

llvm-svn: 219898

Fix for clang crash when instantiating a template with qualified lookup for members in non-class types.
Differential Revision: http://reviews.llvm.org/D5769

llvm-svn: 219897

as load addreses instead of host addresses.
http://reviews.llvm.org/D5735

llvm-svn: 219896

llvm-svn: 219895

llvm-svn: 219894

also reformat to conform to the usual lldb coding conventions
a little better.
clang static analyzer fixit.

llvm-svn: 219893

clang static analyzer fixit.

llvm-svn: 219892

clang static analyzer fixit.

llvm-svn: 219891

We've already created a FileSpec based on this local and 
this code path would never be executed if it is an invalid
FilePath - but the static analyzer doesn't know this and I
want to placate it.
clang static analyzer fixit.

llvm-svn: 219890

clang static analyzer fixits.

llvm-svn: 219889

llvm-svn: 219888

from the previous for() loop - check that it is non-null before trying
to deref it.
clang static analyzer fixit.

llvm-svn: 219887

clang static analyzer fixit.

llvm-svn: 219886

guards around a few additional uses of the cu local pointer.
clang static analyzer fixit.

llvm-svn: 219885

llvm-svn: 219884

Separate out the non-nullable parameters from the nullable ones
(currently only the template template parameter) and demonstrate that
cv-qualifiers aren't preserved for non-null parameters (but are
preserved for null parameters) by adding 'const' to an int* non-type
template parameter.

llvm-svn: 219883

Philip Reames and I had a long conversation about this, mostly because it is
not obvious why the current logic is correct. Hopefully, these comments will
prevent such confusion in the future.

llvm-svn: 219882

llvm-svn: 219881