llvm-svn: 68249

llvm-svn: 68248

llvm-svn: 68247

llvm-svn: 68246

- Finish up support for converting UTF8->UTF16 to support ObjC @"string" constants.

Remove warning from CheckObjCString.

As the FIXME in the test case indicates, I still have a bug to work out (apparently with \u handling).

llvm-svn: 68245

enclosing statement when jumping to a subexpression.

llvm-svn: 68244

llvm-svn: 68243

 - PR3922

 - I have a clean solution for this in flight, but it may take a while
   to come to fruition so we'll take a quick fix for now.

llvm-svn: 68241

clang option code that is and two bug fixes.

llvm-svn: 68240

Patch by Kevin Fan!

llvm-svn: 68239

runtime on 64-bit architectures.
Patch by David Chisnall

llvm-svn: 68238

llvm-svn: 68236

llvm-svn: 68235

class.

llvm-svn: 68234

 - Patch by Ed Schouten!

llvm-svn: 68233

llvm-svn: 68232

llvm-svn: 68231

Clang's test suite.

llvm-svn: 68230

llvm-svn: 68229

- 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