Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLEx

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat

show more ...

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no buil

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).

show more ...

[LLVM] Update formatv() documentation to clarify no escape for `}`

- Update documentation to clarify that `}` does not need to be doubled up.
- Update `EscapedBrace` test case to test this behavior

[LLVM] Update formatv() documentation to clarify no escape for `}`

- Update documentation to clarify that `}` does not need to be doubled up.
- Update `EscapedBrace` test case to test this behavior

Differential Revision: https://reviews.llvm.org/D83888

show more ...

Use C++14-style return type deduction in LLVM.

Summary:
Simplifies the C++11-style "-> decltype(...)" return-type deduction.

Note that you have to be careful about whether the function return type

Use C++14-style return type deduction in LLVM.

Summary:
Simplifies the C++11-style "-> decltype(...)" return-type deduction.

Note that you have to be careful about whether the function return type
is `auto` or `decltype(auto)`. The difference is that bare `auto`
strips const and reference, just like lambda return type deduction. In
some cases that's what we want (or more likely, we know that the return
type is a value type), but whenever we're wrapping a templated function
which might return a reference, we need to be sure that the return type
is decltype(auto).

No functional change.

Subscribers: dexonsmith, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74383

show more ...

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[Support] Require llvm::Error passed to formatv() to be wrapped in fmt_consume()

Summary:
Someone must be responsible for handling an Error. When formatv takes
ownership of an Error, the formatv_obj

[Support] Require llvm::Error passed to formatv() to be wrapped in fmt_consume()

Summary:
Someone must be responsible for handling an Error. When formatv takes
ownership of an Error, the formatv_object destructor must take care of this.

Passing an error by value to formatv() is not considered explicit enough to mark
the error as handled (see D49013), so we require callers to use a format adapter
to confirm this intent.

Reviewers: zturner

Subscribers: llvm-commits, lhames

Differential Revision: https://reviews.llvm.org/D49170

llvm-svn: 336888

show more ...

[Support] Make support types more easily printable.

Summary:
Error's new operator<< is the first way to print an error without consuming it.

formatv() can now print objects with an operator<< that

[Support] Make support types more easily printable.

Summary:
Error's new operator<< is the first way to print an error without consuming it.

formatv() can now print objects with an operator<< that works with raw_ostream.

Reviewers: bkramer

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D48966

llvm-svn: 336412

show more ...

Fix padding with custom character in formatv.

The format string for formatv allows to specify a custom padding
character instead of the default space. This custom character was
parsed correctly, bu

Fix padding with custom character in formatv.

The format string for formatv allows to specify a custom padding
character instead of the default space. This custom character was
parsed correctly, but not passed on to the formatter.

Patch by Marcel Köppe
Differential Revision: https://reviews.llvm.org/D48140

llvm-svn: 335915

show more ...

Fix FormatVariadicTest with GCC

Looks like GCC didn't like the original specialization, try within namespace.

llvm-svn: 316361

Support formatting formatv_objects.

Summary:
Support formatting formatv_objects.

While here, fix documentation about member-formatters, and attempted
perfect-forwarding (I think).

Reviewers: zturn

Support formatting formatv_objects.

Summary:
Support formatting formatv_objects.

While here, fix documentation about member-formatters, and attempted
perfect-forwarding (I think).

Reviewers: zturner

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D38997

llvm-svn: 316330

show more ...

[Support] PR33388 - Fix formatv_object move constructor

formatv_object currently uses the implicitly defined move constructor,
but it is buggy. In typical use-cases, the problem doesn't show-up
beca

[Support] PR33388 - Fix formatv_object move constructor

formatv_object currently uses the implicitly defined move constructor,
but it is buggy. In typical use-cases, the problem doesn't show-up
because all calls to the move constructor are elided. Thus, the buggy
constructors are never invoked.

The issue especially shows-up when code is compiled using the
-fno-elide-constructors compiler flag. For instance, this is useful when
attempting to collect accurate code coverage statistics.

The exact issue is the following:

The Parameters data member is correctly moved, thus making the
parameters occupy a new memory location in the target
object. Unfortunately, the default copying of the Adapters blindly
copies the vector of pointers, leaving each of these pointers
referencing the parameters in the original object instead of the copied
one. These pointers quickly become dangling when the original object is
deleted. This quickly leads to crashes.

The solution is to update the Adapters pointers when performing a move.
The copy constructor isn't useful for format objects and can thus be
deleted.

This resolves PR33388.

Differential Revision: https://reviews.llvm.org/D34463

llvm-svn: 310475

show more ...

[formatv] Add the ability to specify a fill character when aligning.

Previously if you used fmt_align(7, Center) you would get the
output ' 7 '. It may be desirable for the user to specify
the

[formatv] Add the ability to specify a fill character when aligning.

Previously if you used fmt_align(7, Center) you would get the
output ' 7 '. It may be desirable for the user to specify
the fill character though, for example producing '---7---'. This
patch adds that.

llvm-svn: 305449

show more ...

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consi

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.

No other change was made. I did no manual edits, all of this is
clang-format.

This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.

llvm-svn: 304786

show more ...

[Support] Add formatv support for StringLiteral

Summary:
This is achieved by generalizing the expression selecting the StringRef
format_provider. Now, anything that can be converted to a StringRef w

[Support] Add formatv support for StringLiteral

Summary:
This is achieved by generalizing the expression selecting the StringRef
format_provider. Now, anything that can be converted to a StringRef will
use it's formatter.

Reviewers: zturner

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29898

llvm-svn: 295064

show more ...

Simplify format member detection in FormatVariadic

Summary:
This replaces the format member search, which was quite complicated, with a more
direct approach to detecting whether a class should be fo

Simplify format member detection in FormatVariadic

Summary:
This replaces the format member search, which was quite complicated, with a more
direct approach to detecting whether a class should be formatted using the
format-member method. Instead we use a special type llvm::format_adapter, which
every adapter must inherit from. Then the search can be simply implemented with
the is_base_of type trait.

Aside from the simplification, I like this way more because it makes it more
explicit that you are supposed to use this type only for adapter-like
formattings, and the other approach (format_provider overloads) should be used
as a default (a mistake I made when first trying to use this library).

The only slight change in behaviour here is that now choose the format-adapter
branch even if the format member invocation will fail to compile (e.g. because it is a
non-const member function and we are passing a const adapter), whereas
previously we would have gone on to search for format_providers for the type.
However, I think that is actually a good thing, as it probably means the
programmer did something wrong.

Reviewers: zturner, inglorion

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D27679

llvm-svn: 289795

show more ...

Fix MSCV compilation broken by r289040

I wanted to use the "not" keyword to make sure it does not get lost in between
other checks. MSVC does not like that.

llvm-svn: 289041

Improve format member detection in llvm::formatv

Summary:
The existing detection of a format member function has a couple of deficiencies:
- the member function does not get detected if one calls fo

Improve format member detection in llvm::formatv

Summary:
The existing detection of a format member function has a couple of deficiencies:
- the member function does not get detected if one calls formatv with an lvalue,
because the template parameter gets deduced as T&, which fails the is_class
check.
- it also did not work if the function was called with a const variable because
the template parameter would get deduced as const T&, again failing the
is_class check.

This fixes the problem by stripping the references in the uses_format_member
template, to make sure the type is correctly detected as class. It also provides
specializations of the has_FormatMember template for const and non-const members
of the types in order to enable declaring the format member as a "const"
function. I have added tests that verify that formatv can be now called in these
scenarios. As some scenarios could not be verified at runtime (e.g. making sure
that calling a non-const format member on a const object does *not* compile), I
have also added some static_asserts which test the behaviour of the template
classes used internally by formatv().

Reviewers: zturner

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D27525

llvm-svn: 289040

show more ...

[Support] Introduce llvm::formatv() function.

This introduces a new type-safe general purpose formatting
library. It provides compile-time type safety, does not require
a format specifier (since th

[Support] Introduce llvm::formatv() function.

This introduces a new type-safe general purpose formatting
library. It provides compile-time type safety, does not require
a format specifier (since the type is deduced), and provides
mechanisms for extending the format capability to user defined
types, and overriding the formatting behavior for existing types.

This patch additionally adds documentation for the API to the
LLVM programmer's manual.

Mailing List Thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105836.html

Differential Revision: https://reviews.llvm.org/D25587

llvm-svn: 286682

show more ...