This also switches the users in LLVM to ensure this functionality is tested.

llvm-svn: 202705

llvm-svn: 202704

llvm-svn: 202703

a constructor either. Just call the constructor directly. I'll look into
making this work with aggregate initialization some other time (when
I have someone with MSVC 2012 handy to test ideas).

llvm-svn: 202688

operand_values. The first provides a range view over operand Use
objects, and the second provides a range view over the Value*s being
used by those operands.

The naming is "STL-style" rather than "LLVM-style" because we have
historically named iterator methods STL-style, and range methods seem to
have far more in common with their iterator counterparts than with
"normal" APIs. Feel free to bikeshed on this one if you want, I'm happy
to change these around if people feel strongly.

I've switched code in SROA and LCG to exercise these mostly to ensure
they work correctly -- we don't really have an easy way to unittest this
and they're trivial.

llvm-svn: 202687

proposed std::iterator_pair which was in committee suggested to move
toward std::iterator_range. There isn't a formal paper yet, but there
seems little disagreement within the committee at this point so it seems
fine to provide our own version in the llvm namespace so we can easily
build range adaptors for the numerous iterators in LLVM's interfaces.

Note that I'm not really comfortable advocating a crazed range-based
migration just yet. The range stuff is still in a great deal of flux in
C++ and the committee hasn't entirely made up its mind (afaict) about
how it will work. So I'm mostly trying to provide the minimal
functionality needed to make writing easy and convenient range adaptors
for range based for loops easy and convenient. ;]

Subsequent patches will use this across the fundamental IR types, where
there are iterator views.

llvm-svn: 202686

that std::vector constructor.

llvm-svn: 202684

This is used to avoid conflicts with user modules with the same name from different workspaces.

rdar://16042513

llvm-svn: 202683

llvm-svn: 202682

[libclang] Introduce APIs that assist in constructing a simple module.map file for a user framework.

rdar://16092858

llvm-svn: 202681

Determine support for colored output from stdout instead of stderr since that's where the diagnostics go.

llvm-svn: 202680

Allows removing #include's in LLVM while switching to std::unique_ptr.

llvm-svn: 202679

Suggestion by Richard Smith.

llvm-svn: 202678

Allows removing #include's in LLVM while switching to std::unique_ptr.

llvm-svn: 202677

Allows removing #include's in LLVM while switching to std::unique_ptr.

llvm-svn: 202676

Returning CXString is not appropriate if we want to switch to a non-string format buffer.

llvm-svn: 202675

The diagnostics tests were missing from the previous introduction of ifeqs.

llvm-svn: 202674

Implement LWG Paper n3887: Consistent Metafunction Aliases. This adds std::tuple_element_t<> as an alias for tuple_element<>::type. Clean up the synopsis for tuple_element in <utility> as well.

llvm-svn: 202673

Per N3924, mark random_shuffle as deprecated in the synopsis for <algorithm>. Since we don't actually do anything when a call is deprecated, there is no functionality change. Maybe someday, we'll decide to warn when using a deprecated function.

llvm-svn: 202672

Implement LWG Issue #2285 - make_reverse_iterator. Also mark issues #1450 and #2205 as complete; they are just wording changes in the standard. Mark issues #2359, #2320 and #2322 as complete - libc++ implements them already.

llvm-svn: 202671

llvm-svn: 202670

It isn't appropriate for a tool to be stomping over the dependency files,
especially if the actual build uses a compiler other than Clang or the tool
cannot find all the headers for some reason (which would cause the existing
dependency file to be deleted).

If a tool actually needs to care about dependency files we can think about
adding a mechanism for getting to this information.

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

llvm-svn: 202669

The goal is to make it possible for checks to emit diagnostics at levels
other than 'warning'.

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

llvm-svn: 202668

This commit reverts r201037, it's functionality is not needed given the
definition of std::max_align_t in libcxx circa r201843.

llvm-svn: 202667

llvm-svn: 202666

They didn't provide any value over the default ones but blocked move semantics.

llvm-svn: 202664

llvm-svn: 202663

The interaction between defaulted operators and move elision isn't
totally obvious, add a unit test so it doesn't break unintentionally.

llvm-svn: 202662

llvm-svn: 202661

llvm-svn: 202660

Some files had CRLF line terminators, some only had a mixture of
CRLF and LF.  Switch to LF.

llvm-svn: 202659

This adds support for the PPC "wc" inline asm constraint (used for allocating
individual CR bits). Support for this constraint type was recently added to the
LLVM PowerPC backend. Although gcc does not currently support allocating
individual CR bits, this identifier choice has been coordinated with the gcc
PowerPC team, and will be marked as reserved for this purpose in the gcc
constraints.md file.

Prior to this change, none of the multi-character PPC constraints were handled
correctly (the '^' escape character was not being added as required by the
parsing code in LLVM). This should now be fixed. I'll add tests for these other
constraints as support is added for them in the backend.

llvm-svn: 202658

Now that the PowerPC backend can track individual CR bits as first-class
registers, we should also have a way of allocating them for inline asm
statements. Because these registers are only one bit, if an output variable is
implicitly cast to a larger integer size, we'll get an any_extend to that
larger type (this is part of the existing target-independent logic). As a
result, regardless of the size of the output type, only the first bit is
meaningful.

The constraint identifier "wc" has been chosen for this purpose. Although gcc
does not currently support allocating individual CR bits, this identifier
choice has been coordinated with the gcc PowerPC team, and will be marked as
reserved for this purpose in the gcc constraints.md file.

llvm-svn: 202657

llvm-svn: 202656

Adding some cross references to the sanitizer attribute documentation. Removes a Sphinx warning pointed out by Sean Silva.

llvm-svn: 202655

llvm-svn: 202654

llvm-svn: 202653

No intended functionality change.

llvm-svn: 202652

We mostly iterate over read-only values. Following a suggestion by Duncan P.N
Exons Smith, we use the construct 'const auto &' for this.

llvm-svn: 202651

clang-formats behaviour has changed for a couple of C++11 formattings. We adapt
Polly to ensure our formatting checks are clean again.

llvm-svn: 202650