in arc mode and are in system headers as unavailable. 
// rdar://10186625

llvm-svn: 140565

llvm-svn: 140564

llvm-svn: 140563

-mcpu.
 

llvm-svn: 140562

llvm-svn: 140561

llvm-svn: 140560

llvm-svn: 140559

llvm-svn: 140558

Enhance alias analysis for atomic instructions a bit.  Upgrade a couple alias-analysis tests to the new atomic instructions.

llvm-svn: 140557

llvm-svn: 140556

llvm-svn: 140554

llvm-svn: 140553

CheckStringInit has side effects; make sure we don't run it in VerifyOnly mode, at least for the moment.  <rdar://problem/10185490>.

Sebastian, please take a look at this; I'm not entirely sure it is the right thing to do.

llvm-svn: 140552

Related to rdar://10087069.

llvm-svn: 140551

It has been fixed on the lldb side to compensate for bad debug info (line table information).

llvm-svn: 140550

llvm-svn: 140549

llvm-svn: 140548

printing of local offsets

llvm-svn: 140547

Fix a typo in the new VerifyOnly handling in SemaInit.  No visible difference at the moment, as far as I can tell.

llvm-svn: 140546

expression into a separate class.  This class
encapsulates wrapping the function as needed.  I
am also moving from using booleans to indicate
what the expression's language should be to using
lldb::LanguageType instead.

llvm-svn: 140545

is mostly geared towards darwin crash logs at the moment, though
it could be made more generic with a few tweaks. 

The symbolicate-crash.py script will make a target given a crash log
and then symbolicate all frames and expand any frames that had inlined
functions in them to show all frames back to the concrete function. It
will also disassemble around the crash site.

llvm-svn: 140544

llvm-svn: 140543

llvm-svn: 140542

it also populates the variable declaration location if possible.

llvm-svn: 140540

Fix emission of debug data for global variables. getContext() on DIGlobalVariables is not valid any more.

llvm-svn: 140539

message. Specifically, we now only line-wrap the first line of te
diagnostic message and assume the remainder is manually formatted. While
adding it back, simplify the logic for doing this.

Finally, add a test that ensures we actually preserve this feature. =D
*Now* its not dead code. Thanks to Doug for the test case.

llvm-svn: 140538

llvm-svn: 140537

llvm-svn: 140536

llvm-svn: 140535

llvm-svn: 140534

llvm-svn: 140533

llvm-svn: 140532

llvm-svn: 140531

llvm-svn: 140530

little storage.

llvm-svn: 140529

from Stepan Dyatkovskiy. Fixes PR10925.

llvm-svn: 140528

when working with a diagnostic attached to a source location. Also
comment more thoroughly why its important to handle non-location
diagnostic messages separately.

Finally, hoist the creation of the TextDiagnostic object up to the
beginning of the location-based diagnostics. This paves the way for
sinking more and more of the logic into this class. When everything
below this constructor is sunk into the TextDiagnostic class it should
be sufficiently "feature complete" to accomplish my two goals:
1) Have the printing of a macro expansion note use the exact same code
   as any other note.
2) Be able to implement clang_formatDiagnostic in terms of this class.

llvm-svn: 140526

a dedicated path. The logic for such diagnostics is much simpler than
for others.

This begins to make an important separation in this routine. We expect
most (and most interesting) textual diagnostics to be made in the
presence of at least *some* source locations and a source manager.
However the DiagnosticConsumer must be prepared to diagnose errors even
when the source manager doesn't (yet) exist or when there is no location
information at all. In order to sink more and more logic into the
TextDiagnostic class while minimizing its complexity, my plan is to
force the DiagnosticConsumer to special case diagnosing any locationless
messages and then hand the rest to the TextDiagnostic class. I'd
appreciate any comments on this design. It requires a bit of code
duplication in order to keep interfaces simple. Alternatively, if we
really need TextDiagnostic to be capable of handling diagnostics even in
the absence of a viable SourceManager, then this split isn't necessary.

llvm-svn: 140525

function. Doing this conveniently requires moving the word wrapping to
use a StringRef which seems generally an improvement. There is a lot
that could be simplified in the word wrapping by using StringRef that
I haven't looked at yet...

llvm-svn: 140524

functionality changed.

llvm-svn: 140523