Before, clang-format would not break overly long string literals
following a "<<" with FormatStyle::AlwaysBreakBeforeMultilineStrings
being set.

llvm-svn: 187650

llvm-svn: 187649

llvm-svn: 187648

llvm-svn: 187647

llvm-svn: 187646

llvm-svn: 187645

llvm-svn: 187644

A instance of the class always represents a BSS atom, so we don't need
to look at the symbol or the section to retrieve its attributes.

llvm-svn: 187643

Revert r187597, "Bugfix for making the DWARF debug strings and labels to code emitted as secrel32 instead of long opcodes (only for coff). This makes them debuggable with GDB."

It broke x86_64-win32 builder in llvm/test/DebugInfo.

llvm-svn: 187642

Patch by Benjamin Scarlet!

llvm-svn: 187641

It broke the "phase1 - sanity" buildbot. Reverting until
we can figure out what's going on.

And Eric says it broke all current Mac builds actually.

llvm-svn: 187640

in one module but is only declared as a friend in another module, keep it
visible in the result of the merge.

This is incomplete on two axes:

1) Our handling of local extern declarations is basically broken (we put them
in the wrong decl context, and don't find them in redeclaration lookup, unless
they've previously been declared), and this results in them making friends
visible after a merge.

2) Eventually we'll need to mark that this has happened, and more carefully
check whether a declaration should be visible if it was only visible in some
of the modules in which it was declared. Fortunately it's rare for the
identifier namespace of a declaration to change along its redeclaration chain.

llvm-svn: 187639

instructions." in an attempt to bring back some bots.

This reverts commit r187609.

llvm-svn: 187638

This adds a bunch of options to clang-cl. Notably, this includes
all the options that get passed when doing a default build of a
command-line project with msbuild.exe in Debug and Release modes,
and I believe all flags from Reid's original patch.

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

llvm-svn: 187637

1.  I had been detecting and trapping iterator == and \!= among iterators
    in different containers as an error.  But the trapping itself is actually
    an error.
    
    Consider:
    
    #include <iostream>
    #include <vector>
    #include <algorithm>

    template <class C>
    void
    display(const C& c)
    {
        std::cout << "{";
        bool first = true;
        for (const auto& x : c)
        {
            if (\!first)
                std::cout << ", ";
            first = false;
            std::cout << x;
        }
        std::cout << "}\n";
    }

    int
    main()
    {
        typedef std::vector<int> V;
        V v1 = {1, 3, 5};
        V v2 = {2, 4, 6};
        display(v1);
        display(v2);
        V::iterator i = std::find(v1.begin(), v1.end(), 1);
        V::iterator j = std::find(v2.begin(), v2.end(), 2);
        if (*i == *j)
            i = j;    // perfectly legal
        // ...
        if (i \!= j)   // the only way to check
            v2.push_back(*i);
        display(v1);
        display(v2);
    }

    It is legal to assign an iterator from one container to another of the
    same type.  This is required to work.  One might want to test whether or
    not such an assignment had been made.  The way one performs such a check
    is using the iterator's ==, \!= operator.  This is a logical and necessary
    function and does not constitute an error.

2.  I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined.
    This caused a problem in several of the libc++ tests.
    Fixed.

3.  There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that
    std::basic_string is inoperable.  std::basic_string uses __wrap_iterator
    to implement its iterators.  __wrap_iterator has been rigged up in debug
    mode to support vector.  But string hasn't been rigged up yet.  This means
    that one gets false positives when using std::string in debug mode.  I've
    upped std::string's priority in www/debug_mode.html.

llvm-svn: 187636

llvm-svn: 187635

Revert "ObjectiveC migrator. Migrate to instancetype return type for mehods with certain prefix selector matching their class names' suffix."

This reverts commit r187626.

It is breaking the bots.

llvm-svn: 187634

Revert "If -fslp-vectorize or -fno-slp-vectorize are given, honor this selection. If no flag is given, enable it for -O3."

This reverts commit r187630.

Looks like it is breaking the bots.

llvm-svn: 187633

remove lines that are setting DecoderNamespace for pseudo atomic instructions.

No intended functionality change.

llvm-svn: 187632

Patch (mostly) by Adam Strzelecki. Thanks!

Before:
  [self aaaaaa:bbbbbbbbbbbbb
      aaaaaaaaaa:bbbbbbbbbbbbbbbbb
           aaaaa:bbbbbbbbbbb +
      bbbbbbbbbbbb aaaa:bbb];

After:
  [self aaaaaa:bbbbbbbbbbbbb
      aaaaaaaaaa:bbbbbbbbbbbbbbbbb
           aaaaa:bbbbbbbbbbb + bbbbbbbbbbbb
            aaaa:bbb];

This fixes llvm.org/PR16150.

llvm-svn: 187631

If -fslp-vectorize or -fno-slp-vectorize are given, honor this selection. If no flag is given, enable it for -O3.

llvm-svn: 187630

llvm-svn: 187629

llvm-svn: 187628

for mehods with certain prefix selector matching their class names'
suffix.

llvm-svn: 187626

We process autorelease counts when we exit functions, but if there's an
issue in a synthesized body the report will get dropped. Just skip the
processing for now and let it get handled when the caller gets around to
processing autoreleases.

(This is still suboptimal: objects autoreleased in the caller context
should never be warned about when exiting a callee context, synthesized
or not.)

Second half of <rdar://problem/14611722>

llvm-svn: 187625

Much of our diagnostic machinery is set up to assume that the report
end path location is valid. Moreover, the user may be quite confused
when something goes wrong in our BodyFarm-synthesized function bodies,
which may be simplified or modified from the real implementations.
Rather than try to make this all work somehow, just drop the report so
that we don't try to go on with an invalid source location.

Note that we still handle reports whose /paths/ go through invalid
locations, just not those that are reported in one.

We do have to be careful not to lose warnings because of this.
The impetus for this change was an autorelease being processed within
the synthesized body, and there may be other possible issues that are
worth reporting in some way. We'll take these as they come, however.

<rdar://problem/14611722>

llvm-svn: 187624

llvm-svn: 187623

Before:
  some_quite_long_variable_name_ptr
      ?
      : argv[9] ? ptr : argv[8] ? : argv[7] ? ptr : argv[6];
After:
  some_quite_long_variable_name_ptr
      ?: argv[9] ? ptr : argv[8] ?: argv[7] ? ptr : argv[6];

Patch by Adam Strzelecki, thank you!!

This fixed llvm.org/PR16758.

llvm-svn: 187622

around was fixed in llvm commit r186846.
<rdar://problem/14489274> 

llvm-svn: 187620

This unifies the unix and windows versions of FileManager::UniqueDirContainer
and FileManager::UniqueFileContainer by using UniqueID.

We cannot just replace "struct stat" with llvm::sys::fs::file_status, since we
want to be able to construct fake ones, and file_status has different members
on unix and windows.

What the patch does is:

* Record only the information that clang is actually using.
* Use llvm::sys::fs::status instead of stat and fstat.
* Use llvm::sys::fs::UniqueID
* Delete the old windows versions of UniqueDirContainer and
UniqueFileContainer since the "unix" one now works on windows too.

llvm-svn: 187619

Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead of through a random target options
structure.

llvm-svn: 187618

llvm-svn: 187617

The use of sd_dev and st_ino has reached libclang, so expose the two components
in UniqueID so that we can use it in clang.

llvm-svn: 187616

Fixed the Intel-syntax X86 disassembler to respect the (existing) option for hexadecimal immediates, to match AT&T syntax. This also brings a new option for C-vs-MASM-style hex.

Patch by Richard Mitton
Reviewed: http://llvm-reviews.chandlerc.com/D1243

llvm-svn: 187614

This is actually an LLVM bug in the way it generates signatures for these
when soft float is enabled. For example, floor ends up having the signature
of int64(int64). The signature part is not the same as where the actual
parameter types are recorded, and those ARE of course int64(int64) when
soft float is enabled. (Yes, Mips16 hard float uses soft float but with
different runtime rounes but then has to interoperate with Mips32 using
normal floating point). This logic will eventually be moved to the 
Mips16HardFloat pass so it's not worth sorting out these issues in LLVM
since nobody but Mips16 cares about these signatures, as far as I know,
and even I won't eventually either.

llvm-svn: 187613

Without an ODR, the -flimit-debug-info debug info size optimization of
emitting declarations for fully defined types when only a declaration is
needed by the TU, is incorrect. Emit the full definition whenever it's
available in non-C++.

llvm-svn: 187611

ARM/Hexagon testcases can't compile x86 only testcase. Reverting change to testcase & fixing check for all.

llvm-svn: 187610

Also remove checking of llvm.dbg.sp since it is not used in generating dwarf.

Current state of Finder:
DebugInfoFinder tries to list all debug info MDNodes used in a module. To
list debug info MDNodes used by an instruction, DebugInfoFinder provides
processDeclare, processValue and processLocation to handle DbgDeclareInst,
DbgValueInst and DbgLoc attached to instructions. processModule will go
through all DICompileUnits in llvm.dbg.cu and list debug info MDNodes
used by the CUs.

TODO:
1> Finder has a list of CUs, SPs, Types, Scopes and global variables. We
need to add a list of variables that are used by DbgDeclareInst and
DbgValueInst.
2> MDString fields should be null or isa<MDString> and MDNode fields should be
null or isa<MDNode>. We currently use empty string or int 0 to represent null.
3> Go though Verify functions and make sure that they check field types.
4> Clean up existing testing cases to remove llvm.dbg.sp and make sure each
testing case has a llvm.dbg.cu.

llvm-svn: 187609

We emit definitions with no members when a nested type is
referenced/required (GCC does the same, to be fair) but failed to attach
the template arguments in such a case.

llvm-svn: 187608

The absence of members was a poor/incorrect proxy for "is definition".

llvm-svn: 187607