The command-line for clang-apply-replacements was being mangled due to an
uninitialized variable. gasp! Now fixed.

llvm-svn: 192033

Summary:
The clang-apply-replacements process is now invoked to apply
replacements between applying transforms. This resulted in a massive
simplification of the tool:
- FileOverrides class no longer needed.
- Change tracking and code formatting no longer needed.
- No more dependency on libclangApplyReplacements.
- Final syntax check is easier to do directly now than with a separate
  header/source pair.

Replacement handling stuff abstracted into a new header/source pair to
de-clutter ClangModernize.cpp somewhat.

Tests updated.

Differential Revision: http://llvm-reviews.chandlerc.com/D1836

llvm-svn: 192032

llvm-svn: 192031

Patch by Daniel Marjamäki!

llvm-svn: 192030

llvm-svn: 192029

llvm-svn: 192028

This was a leftover from r160847.

llvm-svn: 192027

Add OPC_CheckChildSame0-3 to the DAG isel matcher. This replaces sequences of MoveChild, CheckSame, MoveParent. Saves 846 bytes from the X86 DAG isel matcher, ~300 from ARM, ~840 from Hexagon.

llvm-svn: 192026

llvm-svn: 192025

<rdar://problem/15148224> 

llvm-svn: 192024

llvm-svn: 192023

llvm-svn: 192022

llvm-svn: 192021

Patch by Ashok Thirumurthi

llvm-svn: 192020

DW_TAG_pointer_type is updated to use DITypeRef.

Paired commit with r192018.

llvm-svn: 192019

is updated to use DITypeRef.

Move isUnsignedDIType and getOriginalTypeSize from DebugInfo.h to be static
helper functions in DwarfCompileUnit. We already have a static helper function
"isTypeSigned" in DwarfCompileUnit, and a pointer to DwarfDebug is added to
resolve the derived-from field. All three functions need to go across link
for derived-from fields, so we need to get hold of a type identifier map.

A pointer to DwarfDebug is also added to DbgVariable in order to resolve the
derived-from field.

Debug info verifier is updated to check a derived-from field is a TypeRef.
Verifier will not go across link for derived-from fields, in debug info finder,
we go across the link to add derived-from fields to types.

Function getDICompositeType is only used by dragonegg and since dragonegg does
not generate identifier for types, we use an empty map to resolve the
derived-from field.

When printing a derived-from field, we use DITypeRef::getName to either return
the type identifier or getName of the DIType.

A paired commit at clang is required due to changes to DIBuilder.

llvm-svn: 192018

llvm-svn: 192017

llvm-svn: 192016

llvm-svn: 192015

llvm-svn: 192014

llvm-svn: 192013

llvm-svn: 192012

pointed to by a dbg_value belonging to a function argument is eliminated
during instruction selection.
rdar://problem/15094721.

llvm-svn: 192011

 
I've changed it so we don't set highest level warnings (all) for MSVC when building projects using cmake and instead leave the default. That's /W4 on my machine and seems to be ok.
 
With all warnings on for msvc, we see literally thousands of warnings. 99.99% aren't relevant and just obscure the ones that are.
I think the user can still override things if they want something different from the command line when using cmake.

llvm-svn: 192010

llvm-svn: 192009

Several CF* data formatters were in the AppKit category
This puts them back where they belong, i.e. in category CoreFoundation

llvm-svn: 192008

G M: The attached patch is for libcxx's new.cpp and __config files. The patch's intent is to make new.cpp compile using MS's cl.exe compiler without changing the meaning of anything for any other compiler.

The issue this patch seeks to address is that MS's compiler (cl.exe) doesn't support the __attribute__((__weak__)) or __atribute__((__visibility__("default")) syntax; so a solution must be found where cl.exe doesn't see this syntax.

This patch seeks to solve this problem by changing code patterned like this:
__attribute__((__weak__, __visibility__("default")))
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { /*snip*/; return p; }

to code like this:
_LIBCPP_WEAK
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { return p; }

Howard:  Thanks for all the comments regarding the default visibility
tag on the definition.  I agree it isn't needed, and that there are lots
of other places where it is missing.  That being said, I'm not wanting
to rock the boat on that issue right now.  So I've added it back to the
definition via _LIBCPP_FUNC_VIS.  A later pass dedicated just to this
issue can bring things in to a consistent state one way or the other. 
Note that we do not want to have the exact same attributes on the
declaration and defintion in this case.  The declaration should not be
marked weak, whereas the definition should (which is what G M's patch
did). I've fully tested on OS X to ensure that the resultant attribute
syntax actually works.

llvm-svn: 192007

llvm-svn: 192006

llvm-svn: 192005

llvm-svn: 192004

llvm-svn: 192003

scope, pass a scope.

llvm-svn: 192002

UpdatePHINodes has an optimization to reuse an existing PHI node, where it
first deletes all of its entries and then replaces them. Unfortunately, in the
case where we had duplicate predecessors (which are allowed so long as the
associated PHI entries have the same value), the loop removing the existing PHI
entries from the to-be-reused PHI would assert (if that PHI was not the one
which had the duplicates).

llvm-svn: 192001

llvm-svn: 192000

llvm-svn: 191999

* two actually due to some weird template thing... investigating that.

llvm-svn: 191998

llvm-svn: 191997

This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases

More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff:
this ValueObject does not have a summary
its children have no synthetic children
its children are not a non-empty base class without a summary
its children do not have a summary that asks for children to show up
the aggregate length of all the names of all the children is <= 50 characters
you did not ask to see the types during a printout
your pointer depth is 0

This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?)

Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be)

llvm-svn: 191996

llvm-svn: 191995

llvm-svn: 191994