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 ...