rdar://13254235

llvm-svn: 176036

Don't print the semicolon when visiting an empty declaration because the semicolon
will be printed as a terminator later.

llvm-svn: 176035

While RegionStore checks to make sure casts on TypedValueRegions are valid,
it does not do the same for SymbolicRegions, which do not have perfect type
info anyway. Additionally, MemRegion::getAsOffset does not take a
ProgramState, so it can't use dynamic type info to determine a better type
for the regions. (This could also be dangerous if the type of a super-region
changes!)

Account for this by checking that a base object region is valid on top of a
symbolic region, and falling back to "symbolic offset" mode if not.

Fixes PR15345.

llvm-svn: 176034

llvm-svn: 176033

llvm-svn: 176032

llvm-svn: 176031

Report and fix due to Kai Nacke.  Testcase update by me.

llvm-svn: 176029

This fixes llvm.org/PR15350.

Before:
Constructor(int Parameter = 0)
    : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa),
                aaaaaaaaaaaa(aaaaaaaaaaaaaaaaa) {}

After:
Constructor(int Parameter = 0)
    : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa),
      aaaaaaaaaaaa(aaaaaaaaaaaaaaaaa) {}

I think the correct solution is to put the VariablePos into
ParenState, not LineState. Added FIXME.

llvm-svn: 176027

llvm-svn: 176026

TemplateSpecializationType doesn't quite have getDecl(). Need to go
through TemplateName to get a TemplateDecl.

Added test cases for the hasDeclaration() overload for
TemplateSpecializationType. Also introduced the type matcher
templateSpecializationType() used by the new hasDeclaration() test case.

Updated LibASTMatchersReference.

Reviewers: klimek
llvm-svn: 176025

Re-introducing r175532. The has_getDecl metafunction didn't compile with
Visual Studio. This revision uses approaches has_getDecl from a
different angle that isn't a problem for Visual Studio.

Added dedicated tests for the metafunction.

Reviewers: klimek
llvm-svn: 176024

llvm-svn: 176023

memory intrinsics in the SDAG builder.

When alignment is zero, the lang ref says that *no* alignment
assumptions can be made. This is the exact opposite of the internal API
contracts of the DAG where alignment 0 indicates that the alignment can
be made to be anything desired.

There is another, more explicit alignment that is better suited for the
role of "no alignment at all": an alignment of 1. Map the intrinsic
alignment to this early so that we don't end up generating aligned DAGs.

It is really terrifying that we've never seen this before, but we
suddenly started generating a large number of alignment 0 memcpys due to
the new code to do memcpy-based copying of POD class members. That patch
contains a bug that rounds bitfield alignments down when they are the
first field. This can in turn produce zero alignments.

This fixes weird crashes I've seen in library users of LLVM on 32-bit
hosts, etc.

llvm-svn: 176022

llvm-svn: 176021

llvm-svn: 176020

Re-introducing r175532. The has_getDecl metafunction didn't compile with Visual
Studio. This revision approaches has_getDecl from a different angle that isn't
a problem for Visual Studio.

Added dedicated tests for the metafunction.

Reviewers: klimek
llvm-svn: 176019

llvm-svn: 176018

Also, add matchers isPrivate(), isProtected() and isPublic(), that
restrict the matching of such AccessSpecDecls and all other Decls.

llvm-svn: 176017

[Sanitizer] fix signed/unsigned compare warnings in sanitizer_stacktrace_test. Build sanitizer_common tests with -Werror as we use predictable just-built Clang for building them

llvm-svn: 176014

llvm-svn: 176013

llvm-svn: 176012

[analyzer] Relax assumption in FindLastStoreBRVisitor that the thing we are looking for is always a VarRegion.

This was triggering assertion failures when analyzing the LLVM codebase.  This
is fallout from r175988.

I've got delta chewing away on a test case, but I wanted the fix to go
in now.

llvm-svn: 176011

r175988 modified the ExplodedGraph trimming algorithm to retain all
nodes for "lvalue" expressions.  This patch refines that notion to
only "interesting" expressions that would be used for diagnostics.

llvm-svn: 176010

This is an ongoing process. Any command line option which a back-end cares about
should be added here.

llvm-svn: 176009

Need available CPU on target device to support CPU reporting.

llvm-svn: 176008

llvm-svn: 176007

llvm-svn: 176005

llvm-svn: 176004

llvm-svn: 176003

llvm-svn: 176002

Moving initialization into the initializer list and correcting capitalization, as suggested by Chandler.

llvm-svn: 176001

llvm-svn: 176000

This fixes llvm.org/PR14967 and is generall necessary to avoid
situations where the column limit is exceeded. The challenge is
restricting such lines splits, otherwise clang-format suddenly starts
breaking at bad places.

Before:
ReallyLongReturnType<TemplateParam1, TemplateParam2>
ReallyReallyLongFunctionName(
    const std::string &SomeParameter,
    const SomeType<string,
                   SomeOtherTemplateParameter> &ReallyReallyLongParameterName,
    const SomeType<string,
                   SomeOtherTemplateParameter> &AnotherLongParameterName) {}

After:
ReallyLongReturnType<TemplateParam1, TemplateParam2>
ReallyReallyLongFunctionName(
    const std::string &SomeParameter,
    const SomeType<string, SomeOtherTemplateParameter> &
        ReallyReallyLongParameterName,
    const SomeType<string, SomeOtherTemplateParameter> &
        AnotherLongParameterName) {}

llvm-svn: 175999

This removes a const_cast hack from PPCRegisterInfo::hasReservedSpillSlot().
The proper place to save the frame index for the CR spill slot is in the
PPCFunctionInfo object, not the PPCRegisterInfo object.

No new test cases, as this just reimplements existing function.  Existing
tests such as test/CodeGen/PowerPC/crsave.ll are sufficient.

llvm-svn: 175998

llvm-svn: 175997

The error is a bit strange tbh, but better than crashing.

llvm-svn: 175996

This is a common pattern with dyn_cast and similar constructs, when the
PHI no longer depends on the select it can often be turned into a simpler
construct or even get hoisted out of the loop.

PR15340.

llvm-svn: 175995

llvm-svn: 175994

llvm-svn: 175993

llvm-svn: 175992