ManagedStatic: remove many straightforward uses in llvm

(Reapply after revert in e9ce1a588030d8d4004f5d7e443afe46245e9a92 due to
Fuchsia test failures. Removed changes in lib/ExecutionEngine/ other

ManagedStatic: remove many straightforward uses in llvm

(Reapply after revert in e9ce1a588030d8d4004f5d7e443afe46245e9a92 due to
Fuchsia test failures. Removed changes in lib/ExecutionEngine/ other
than error categories, to be checked in more detail and reapplied
separately.)

Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,
moving the static variable directly into the only function that uses it.

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

show more ...

Revert "ManagedStatic: remove many straightforward uses in llvm"

This reverts commit e6f1f062457c928c18a88c612f39d9e168f65a85.

Reverting due to a failure on the fuchsia-x86_64-linux buildbot.

ManagedStatic: remove many straightforward uses in llvm

Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,

ManagedStatic: remove many straightforward uses in llvm

Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,
moving the static variable directly into the only function that uses it.

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

show more ...

[unittests] fix intermittent SupportTests failures

by invoking `SupportTests --gtest_shuffle=1`.

`HideUnrelatedOptions`/`HideUnrelatedOptionsMulti` failed due to other
tests calling `cl::ResetComma

[unittests] fix intermittent SupportTests failures

by invoking `SupportTests --gtest_shuffle=1`.

`HideUnrelatedOptions`/`HideUnrelatedOptionsMulti` failed due to other
tests calling `cl::ResetCommandLineParser()` which causes default
options to be removed.

`ExitOnError` would hang due to the threading environment. Renaming it
as `*Deathtest` is the recommended practice by GTest docs.

show more ...

[NFCI][Support] Avoid ASSERT_/EXPECT_TRUE(A <op> B)

The error messages in tests are far better when a test fails if the test
is written using ASSERT_/EXPECT_<operator>(A, B) rather than
ASSERT_/EXPE

[NFCI][Support] Avoid ASSERT_/EXPECT_TRUE(A <op> B)

The error messages in tests are far better when a test fails if the test
is written using ASSERT_/EXPECT_<operator>(A, B) rather than
ASSERT_/EXPECT_TRUE(A <operator> B).

This commit updates all of llvm/unittests/Support to use these macros
where possible.

This change has not been possible in:
- llvm/unittests/Support/FSUniqueIDTest.cpp - due to not overloading
operators beyond ==, != and <.
- llvm/unittests/Support/BranchProbabilityTest.cpp - where the unchanged
tests are of the operator overloads themselves.

There are other possibilities of this conversion not being valid, which
have not applied in these tests, as they do not use NULL (they use
nullptr), and they do not use const char* (they use std::string or
StringRef).

Reviewed By: mubashar_

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

show more ...

Support: Pass wrapped Error's error code through FileError

Change FileError to pass through the error code from the Error it wraps.
This allows APIs that return ECError to transition to FileError wi

Support: Pass wrapped Error's error code through FileError

Change FileError to pass through the error code from the Error it wraps.
This allows APIs that return ECError to transition to FileError without
changing returned std::error_code.

This was extracted from https://reviews.llvm.org/D109345.

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

show more ...

Support: Add Expected<T>::moveInto() to avoid extra names

Expected<T>::moveInto() takes as an out parameter any `OtherT&` that's
assignable from `T&&`. It moves any stored value before returning
tak

Support: Add Expected<T>::moveInto() to avoid extra names

Expected<T>::moveInto() takes as an out parameter any `OtherT&` that's
assignable from `T&&`. It moves any stored value before returning
takeError().

Since moveInto() consumes both the Error and the value, it's only
anticipated that we'd use call it on temporaries/rvalues, with naming
the Expected first likely to be an anti-pattern of sorts (either you
want to deal with both at the same time, or you don't). As such,
starting it out as `&&`-qualified... but it'd probably be fine to drop
that if there's a good use case for lvalues that appears.

There are two common patterns that moveInto() cleans up:
```
// If the variable is new:
Expected<std::unique_ptr<int>> ExpectedP = makePointer();
if (!ExpectedP)
return ExpectedP.takeError();
std::unique_ptr<int> P = std::move(*ExpectedP);

// If the target variable already exists:
if (Expected<T> ExpectedP = makePointer())
P = std::move(*ExpectedP);
else
return ExpectedP.takeError();
```
moveInto() takes less typing and avoids needing to name (or leak into
the scope) an extra variable.
```
// If the variable is new:
std::unique_ptr<int> P;
if (Error E = makePointer().moveInto(P))
return E;

// If the target variable already exists:
if (Error E = makePointer().moveInto(P))
return E;
```

It also seems useful for unit tests, to log errors (but continue) when
there's an unexpected failure. E.g.:
```
// Crash on error, or undefined in non-asserts builds.
std::unique_ptr<MemoryBuffer> MB = cantFail(makeMemoryBuffer());

// Avoid crashing on error without moveInto() :(.
Expected<std::unique_ptr<MemoryBuffer>>
ExpectedMB = makeMemoryBuffer();
ASSERT_THAT_ERROR(ExpectedMB.takeError(), Succeeded());
std::unique_ptr<MemoryBuffer> MB = std::move(ExpectedMB);

// Avoid crashing on error with moveInto() :).
std::unique_ptr<MemoryBuffer> MB;
ASSERT_THAT_ERROR(makeMemoryBuffer().moveInto(MB), Succeeded());
```

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

show more ...

Error: Improve unit test by using gtest equality rather than explicit string compare calls

This ensures error messages from gtest includes the raw text of both
sides of the comparison - otherwise al

Error: Improve unit test by using gtest equality rather than explicit string compare calls

This ensures error messages from gtest includes the raw text of both
sides of the comparison - otherwise all gtest can report is the text of
the expression source, without any information about the values or how
they differ.

show more ...

FileError: Provide a way to retrieve the underlying error string without the file name

For use with APIs that want to report the file name in a different
syntactic form, have other knowledge of the

FileError: Provide a way to retrieve the underlying error string without the file name

For use with APIs that want to report the file name in a different
syntactic form, have other knowledge of the filename, etc.

show more ...

FileError: Support zero-length file names

It's a common error in an API - to try to open an empty file, so it
seems like a reasonable FileError to produce "hey, you tried to open an
empty file" and

FileError: Support zero-length file names

It's a common error in an API - to try to open an empty file, so it
seems like a reasonable FileError to produce "hey, you tried to open an
empty file" and to handle it the same way as any other file error.

show more ...

[NFC] Mark Expected<T>::assertIsChecked() as const

Some const methods of Expected<T> invoke assertIsChecked(),
so we should mark it as const too.

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

[NFC] Mark Expected<T>::assertIsChecked() as const

Some const methods of Expected<T> invoke assertIsChecked(),
so we should mark it as const too.

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

show more ...

[Error/unittests] Add a FailedWithMessage gtest matcher

Summary:
We already have a "Failed" matcher, which can be used to check any
property of the Error object. However, most frequently one just wa

[Error/unittests] Add a FailedWithMessage gtest matcher

Summary:
We already have a "Failed" matcher, which can be used to check any
property of the Error object. However, most frequently one just wants to
check the error message, and while this is possible with the "Failed"
matcher, it is also very convoluted
(Failed<ErrorInfoBase>(testing::Property(&ErrorInfoBase::message, "the
message"))).

Now, one can just write: FailedWithMessage("the message"). I expect that
most of the usages will remain this simple, but the argument of the
matcher is not limited to simple strings -- the argument of the matcher
can be any other matcher, so one can write more complicated assertions
if needed (FailedWithMessage(ContainsRegex("foo|bar"))). If one wants to
match multiple error messages, he can pass multiple arguments to the
matcher.

If one wants to match the message list as a whole (perhaps to check the
message count), I've also included a FailedWithMessageArray matcher,
which takes a single matcher receiving a vector of error message
strings.

Reviewers: sammccall, dblaikie, jhenderson

Subscribers: llvm-commits

Tags: #llvm

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

show more ...

ErrorTest: Break up "ErrorMatchers" test

This test was getting a bit long. Before adding more checks, group the
existing checks according to the matcher used, and break it up into
smaller tests.

[Error] Make llvm::cantFail include the original error messages

Summary:
The current implementation eats the current errors and just outputs
the message parameter passed to llvm::cantFail. This cha

[Error] Make llvm::cantFail include the original error messages

Summary:
The current implementation eats the current errors and just outputs
the message parameter passed to llvm::cantFail. This change appends
the original error message(s), so the user can see exactly why
cantFail failed. New logic is conditional on NDEBUG.

Reviewed By: lhames

Tags: #llvm

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

llvm-svn: 375176

show more ...

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

This reverts commit r368849, because it breaks some bots (e.g.
llvm-clang-x86_64-win-fast).

It turns out this is not as NFC as we h

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

This reverts commit r368849, because it breaks some bots (e.g.
llvm-clang-x86_64-win-fast).

It turns out this is not as NFC as we had hoped, because operator== will
consider two std::error_codes to be distinct even though they both hold
"success" values if they have different categories.

llvm-svn: 368854

show more ...

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