- When processing BlockEdges with terminators, using the condition as the
  control-flow point for terminators that are expressions (e.g., '&&', '?')
- When processing events, allow intra-compound statement "jumping"

llvm-svn: 68228

is appropriate. This helps visually differentiate host-oriented
calculations from target-oriented calculations.

llvm-svn: 68227

llvm-svn: 68223

llvm-svn: 68222

clang option code that is.

llvm-svn: 68221

llvm-svn: 68220

less ambiguous and less C-specific.

llvm-svn: 68219

assembly.

llvm-svn: 68218

start of the function/method.

llvm-svn: 68217

intra-compound statement jumps unless they are between terminators (i.e.,
branches).

llvm-svn: 68216

llvm-svn: 68215

llvm-svn: 68214

http://llvm.org/viewvc/llvm-project?view=rev&revision=68177

llvm-svn: 68213

llvm-svn: 68212

  Applications/Burg/burg
  Applications/ClamAV/clamscan
and many other tests.

llvm-svn: 68211

llvm-svn: 68210

llvm-svn: 68209

#ifdef'd out the 5 conversion routines that we don't currently need.

Still need a bit more work in GetAddrOfConstantCFString(). Added a FIXME to indicate this.

Expect to remove the FIXME today...

llvm-svn: 68208

heuristics to determine when it's useful to desugar a type for display
to the user. Introduce two C++-specific heuristics:

  - For a qualified type (like "foo::bar"), only produce a new
    desugred type if desugaring the qualified type ("bar", in this
    case) produces something interesting. For example, if "foo::bar"
    refers to a class named "bar", don't desugar. However, if
    "foo::bar" refers to a typedef of something else, desugar to that
    something else. This gives some useful desugaring such as
    "foo::bar (aka 'int')".
  - Don't desugar class template specialization types like
    "basic_string<char>" down to their underlying "class
    basic_string<char, char_traits<char>, allocator<char>>, etc.";
    it's better just to leave such types alone. 

Update diagnostics.html with some discussion and examples of type
preservation in C++, showing qualified names and class template
specialization types.

llvm-svn: 68207

llvm-svn: 68206

llvm-svn: 68205

real-world header files and these tests have caught serious bugs in the past.

llvm-svn: 68204

Patch by Jean-Daniel Dupas. Thanks!

llvm-svn: 68203

llvm-svn: 68198

 - Small structures are returned in a register if: 
    1. They fit nicely in a  register.
    2. All fields fit nicely in a register.
   (more or less)

 - We now pass the first 5000 ABITests if unions are disabled.

 - <rdar://problem/6497882> [irgen] x86-32 ABI compatibility with
   small structs

llvm-svn: 68197

element structures", which have different ABI rules.
 - Current return-arguments-32 status is: 1 out of 1000 failures (-7)

 - Also, vectors inside "single element structs" require special
   handling.

llvm-svn: 68196

should only be an error if that value is consumed. This fix was largely
accomplished by moving 'isConsumedExpr' back to ParentMap.

llvm-svn: 68195

types.  It is no longer needed now that the code generator 
re-lays-out interfaces if they are defines after being laid out
from a forward decl.

llvm-svn: 68194

  instead of a FullSourceLoc. This resulted in a bunch of small edits in various
  clients.
- Updated BugReporter to include an alternate PathDiagnostic generation
  algorithm for PathDiagnosticClients desiring more control-flow pieces.

llvm-svn: 68193

 - Current return-arguments-32 status is: 8 out of 1000 failures (-7)

llvm-svn: 68192

llvm-svn: 68191

llvm-svn: 68190

 - <rdar://problem/6741594> [pth] don't abuse -x to drive pth
   generation

 - Simpler, and fixes PR3915.

Cleanup test cases for PTH:
 - Update to use -emit-pth

 - Removed PTH test of carbon.c and cocoa.mm; these didn't actually
   verify anything, and since PTH is token based the extra coverage
   (over cocoa.m) isn't particularly helpful.

 - Split PTH tests in cocoa.m to cocoa-pth.m, solely to increase
   available parallelism when running tests.

Ted, could you update the PTH test cases (include-pth.c and
cocoa-pth.m) to have some sort of positive check that the PTH is
getting used? "# of PTH cache hits" or "tokens read from PTH cache"
statistics would work great. :)

llvm-svn: 68189

llvm-svn: 68188

Based on a patch by Nicolas Trangez on the unladen-swallow mailing list!

llvm-svn: 68187

 - <rdar://problem/6732143> Crash when generating @synchronize for
   zero-cost exception

 - Thanks to Anders for helping track down the problem.

llvm-svn: 68186

distinguish between the true and false branches for path-sensitive analyses.

llvm-svn: 68185

 -  c.f. r68164

llvm-svn: 68184

llvm-svn: 68183

case.

llvm-svn: 68182