raw_ostream: add operator<< overload for std::error_code

Summary:
The main motivation for this is unit tests, which contain a large macro
for pretty-printing std::error_code, and this macro is dupli

raw_ostream: add operator<< overload for std::error_code

Summary:
The main motivation for this is unit tests, which contain a large macro
for pretty-printing std::error_code, and this macro is duplicated in
every file that needs to do this. However, the functionality may be
useful elsewhere too.

In this patch I have reimplemented the existing ASSERT_NO_ERROR macros
to reuse the new functionality, but I have kept the macro (as a
one-liner) as it is slightly more readable than ASSERT_EQ(...,
std::error_code()).

Reviewers: sammccall, ilya-biryukov

Subscribers: zturner, llvm-commits

Tags: #llvm

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

llvm-svn: 368849

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] Make error banner optional in logAllUnhandledErrors

In a lot of places an empty string was passed as the ErrorBanner to
logAllUnhandledErrors. This patch makes that argument optional to
si

[Support] Make error banner optional in logAllUnhandledErrors

In a lot of places an empty string was passed as the ErrorBanner to
logAllUnhandledErrors. This patch makes that argument optional to
simplify the call sites.

llvm-svn: 346604

show more ...

[Error] Reintroduce type validation in createFileError()

This prevents from using ErrorSuccess as an argument to createFileError().

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

llvm-svn:

[Error] Reintroduce type validation in createFileError()

This prevents from using ErrorSuccess as an argument to createFileError().

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

llvm-svn: 341689

show more ...

More build fix for r341064.

llvm-svn: 341070

[Error] Add FileError helper; upgrade StringError behavior

FileError is meant to encapsulate both an Error and a file name/path. It should be used in cases where an Error occurs deep down the call c

[Error] Add FileError helper; upgrade StringError behavior

FileError is meant to encapsulate both an Error and a file name/path. It should be used in cases where an Error occurs deep down the call chain, and we want to return it to the caller along with the file name.

StringError was updated to display the error messages in different ways. These can be:

1. display the error_code message, and convert to the same error_code (ECError behavior)
2. display an arbitrary string, and convert to a provided error_code (current StringError behavior)
3. display both an error_code message and a string, in this order; and convert to the same error_code

These behaviors can be triggered depending on the constructor. The goal is to use StringError as a base class, when a library needs to provide a explicit Error type.

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

llvm-svn: 341064

show more ...

[Support] Add a basic C API for llvm::Error.

Summary:
The C-API supports consuming errors, converting an error to a string error
message, and querying an error's type. Other LLVM C APIs that wish to

[Support] Add a basic C API for llvm::Error.

Summary:
The C-API supports consuming errors, converting an error to a string error
message, and querying an error's type. Other LLVM C APIs that wish to use
llvm::Error can supply error-type-id checkers and custom
error-to-structured-type converters for any custom errors they provide.

Reviewers: bogner, zturner, labath, dblaikie

Subscribers: llvm-commits

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

llvm-svn: 339802

show more ...

[Support] Introduce createStringError helper function

The function in question is copy-pasted lots of times in DWARF-related classes.
Thus it will make sense to place its implementation into the Sup

[Support] Introduce createStringError helper function

The function in question is copy-pasted lots of times in DWARF-related classes.
Thus it will make sense to place its implementation into the Support library.

Reviewed by: lhames

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

llvm-svn: 337995

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

[Testing/Support] Make Failed() matcher work with abstract error types

Failed<ErrorInfoBase>() did not compile, because it was attempting to
create a copy of the Error object when passing it to the

[Testing/Support] Make Failed() matcher work with abstract error types

Failed<ErrorInfoBase>() did not compile, because it was attempting to
create a copy of the Error object when passing it to the nested matcher,
which was not possible because ErrorInfoBase is abstract.

This commit fixes the problem by making sure we pass the ErrorInfo
object by reference, which also improves the handling of non-abstract
objects, as we avoid potentially slicing an object during the copy.

llvm-svn: 329703

show more ...

[Testing/Support]: Better matching of Error failure states

Summary:
The existing Failed() matcher only allowed asserting that the operation
failed, but it was not possible to verify any details of t

[Testing/Support]: Better matching of Error failure states

Summary:
The existing Failed() matcher only allowed asserting that the operation
failed, but it was not possible to verify any details of the returned
error.

This patch adds two new matchers, which make this possible:
- Failed<InfoT>() verifies that the operation failed with a single error
of a given type.
- Failed<InfoT>(M) additionally check that the contained error info
object is matched by the nested matcher M.

To make these work, I've changed the implementation of the ErrorHolder
class. Now, instead of just storing the string representation of the
Error, it fetches the ErrorInfo objects and stores then as a list of
shared pointers. This way, ErrorHolder remains copyable, while still
retaining the full information contained in the Error object.

In case the Error object contains two or more errors, the new matchers
will fail to match, instead of trying to match all (or any) of the
individual ErrorInfo objects. This seemed to be the most sensible
behavior for when one wants to match exact error details, but I could be
convinced otherwise...

Reviewers: zturner, lhames

Subscribers: llvm-commits

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

llvm-svn: 329288

show more ...

[Testing/Support] Make the HasValue matcher composable

Summary:
This makes it possible to run an arbitrary matcher on the value
contained within the Expected<T> object.

To do this, I've needed to f

[Testing/Support] Make the HasValue matcher composable

Summary:
This makes it possible to run an arbitrary matcher on the value
contained within the Expected<T> object.

To do this, I've needed to fully spell out the matcher, instead of using
the shorthand MATCHER_P macro.

The slight gotcha here is that standard template deduction will fail if
one tries to match HasValue(47) against an Expected<int &> -- the
workaround is to use HasValue(testing::Eq(47)).

The explanations produced by this matcher have changed a bit, since now
we delegate to the nested matcher to print the value. Since these don't
put quotes around the value, I've changed our PrintTo methods to match.

Reviewers: zturner

Subscribers: llvm-commits

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

llvm-svn: 320561

show more ...

[Testing/Support] Make matchers work with Expected<T&>

Summary:
This did not work because the ExpectedHolder was trying to hold the
value in an Optional<T*>. Instead of trying to mimic the behavior

[Testing/Support] Make matchers work with Expected<T&>

Summary:
This did not work because the ExpectedHolder was trying to hold the
value in an Optional<T*>. Instead of trying to mimic the behavior of
Expected and try to make ExpectedHolder work with references and
non-references, I simply store the reference to the Expected object in
the holder.

I also add a bunch of tests for these matchers, which have helped me
flesh out some problems in my initial implementation of this patch, and
uncovered the fact that we are not consistent in quoting our values in
the matcher output (which I also fix).

Reviewers: zturner, chandlerc

Subscribers: mgorny, llvm-commits

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

llvm-svn: 320025

show more ...

[Error] Add an optional error message to cantFail.

cantFail is the moral equivalent of an assertion that the wrapped call must
return a success value. This patch allows clients to include an associa

[Error] Add an optional error message to cantFail.

cantFail is the moral equivalent of an assertion that the wrapped call must
return a success value. This patch allows clients to include an associated
error message (the same way they would for an assertion for llvm_unreachable).

If the error message is not specified it will default to: "Failure value
returned from cantFail wrapped call".

llvm-svn: 312066

show more ...

[Error] Add a handleExpected utility.

handleExpected is similar to handleErrors, but takes an Expected<T> as its first
input value and a fallback functor as its second, followed by an arbitary list

[Error] Add a handleExpected utility.

handleExpected is similar to handleErrors, but takes an Expected<T> as its first
input value and a fallback functor as its second, followed by an arbitary list
of error handlers (equivalent to the handler list of handleErrors). If the first
input value is a success value then it is returned from handleErrors
unmodified. Otherwise the contained error(s) are passed to handleErrors, along
with the handlers. If handleErrors returns success (indicating that all errors
have been handled) then handleExpected runs the fallback functor and returns its
result. If handleErrors returns a failure value then the failure value is
returned and the fallback functor is never run.

This simplifies the process of re-trying operations that return Expected values.
Without this utility such retry logic is cumbersome as the internal Error must
be explicitly extracted from the Expected value, inspected to see if its
handleable and then consumed:

enum FooStrategy { Aggressive, Conservative };
Expected<Foo> tryFoo(FooStrategy S);

Expected<Foo> Result;
(void)!!Result; // "Check" Result so that it can be safely overwritten.
if (auto ValOrErr = tryFoo(Aggressive))
Result = std::move(ValOrErr);
else {
auto Err = ValOrErr.takeError();
if (Err.isA<HandleableError>()) {
consumeError(std::move(Err));
Result = tryFoo(Conservative);
} else
return std::move(Err);
}

with handleExpected, this can be re-written as:

auto Result =
handleExpected(
tryFoo(Aggressive),
[]() { return tryFoo(Conservative); },
[](HandleableError&) { /* discard to handle */ });

llvm-svn: 311870

show more ...

Fix two (three) more issues with unchecked Error.

Summary:
If assertions are disabled, but LLVM_ABI_BREAKING_CHANGES is enabled,
this will cause an issue with an unchecked Success. Switching to
cons

Fix two (three) more issues with unchecked Error.

Summary:
If assertions are disabled, but LLVM_ABI_BREAKING_CHANGES is enabled,
this will cause an issue with an unchecked Success. Switching to
consumeError() is the correct way to bypass the check. This patch also
includes disabling 2 tests that can't work without assertions enabled,
since llvm_unreachable() with NDEBUG won't crash.

Reviewers: llvm-commits, lhames

Reviewed By: lhames

Subscribers: lhames, pirama

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

llvm-svn: 311739

show more ...

[Support] Rewrite handleAllErrors in terms of cantFail.

This just switches handleAllErrors from using custom assertions that all errors
have been handled to using cantFail. This change involves movi

[Support] Rewrite handleAllErrors in terms of cantFail.

This just switches handleAllErrors from using custom assertions that all errors
have been handled to using cantFail. This change involves moving some of the
class and function definitions around though.

llvm-svn: 311631

show more ...

fix typos in comments; NFC

llvm-svn: 307626

Add a cantFail overload for Expected-reference (Expected<T&>) types.

llvm-svn: 305863

[Support][Error] Add a 'cantFail' utility function for known-safe calls to
fallible functions.

Some fallible functions (those returning Error or Expected<T>) may only fail
for a subset of their inpu

[Support][Error] Add a 'cantFail' utility function for known-safe calls to
fallible functions.

Some fallible functions (those returning Error or Expected<T>) may only fail
for a subset of their inputs. For example, a "safe" square root function will
succeed for all finite positive inputs:

Expected<double> safeSqrt(double d) {
if (d < 0 && !isnan(d) && !isinf(d))
return make_error<...>("Cannot sqrt -ve values, nans or infs");
return sqrt(d);
}

At a safe callsite for such a function, checking the error return value is
redundant:

if (auto ValOrErr = safeSqrt(42.0)) {
// use *ValOrErr.
} else
llvm_unreachable("safeSqrt should always succeed for +ve values");

The cantFail function wraps this check and extracts the contained value,
simplifying control flow:

double Result = cantFail(safeSqrt(42.0));

This function should be used with care: it is a programmatic error to wrap a
call with cantFail if it can in fact fail. For debug builds this will
result in llvm_unreachable being called. For release builds the behavior is
undefined.

Use of this function is likely to be rare in library code, but more common
for tool and unit-test code where inputs and mock functions may be known to be
safe.

llvm-svn: 296384

show more ...

Fix macro check for ABI breacking check: should use #if instead of #ifndef

llvm-svn: 288265

Change Error unittest to use the LLVM_ENABLE_ABI_BREAKING_CHECKS instead of NDEBUG

This is consistent with the header (after r288087) and fixes the
test for the configuration:
-DLLVM_ENABLE_ASSERT

Change Error unittest to use the LLVM_ENABLE_ABI_BREAKING_CHECKS instead of NDEBUG

This is consistent with the header (after r288087) and fixes the
test for the configuration:
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ABI_BREAKING_CHECKS=FORCE_OFF

llvm-svn: 288196

show more ...

Prevent at compile time converting from Error::success() to Expected<T>

This would trigger an assertion at runtime otherwise.

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

llvm-svn: 286562

Make the Error class constructor protected

This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.

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

Make the Error class constructor protected

This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.

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

llvm-svn: 286561

show more ...

[Support] Make ErrorAsOutParameter take an Error* rather than an Error&.

This allows ErrorAsOutParameter to work better with "optional" errors. For
example, consider a function where for certain inp

[Support] Make ErrorAsOutParameter take an Error* rather than an Error&.

This allows ErrorAsOutParameter to work better with "optional" errors. For
example, consider a function where for certain input values it is known that
the function can't fail. This can now be written as:

Result foo(Arg X, Error *Err) {
ErrorAsOutParameter EAO(Err);

if (<Error Condition>) {
if (Err)
*Err = <report error>;
else
llvm_unreachable("Unexpected failure!");
}
}

Rather than having to construct an ErrorAsOutParameter under every conditional
where Err is known to be non-null.

llvm-svn: 276430

show more ...