[llvm] Use std::make_unique (NFC) (#97165)

This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
std::unique_ptr<Type>(new

[llvm] Use std::make_unique (NFC) (#97165)

This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
std::unique_ptr<Type>(new Type()), which is a bit mouthful.

show more ...

Reland "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 632a389f96355cbe7ed8fa7b8d2ed6267c92457c.

This relands commit
1834a310d060d55748ca38d4ae0482864c2047d8.

Differential R

Reland "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 632a389f96355cbe7ed8fa7b8d2ed6267c92457c.

This relands commit
1834a310d060d55748ca38d4ae0482864c2047d8.

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

show more ...

Revert "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 1834a310d060d55748ca38d4ae0482864c2047d8.

[llvm][NFC] Use c++17 style variable type traits

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: dblaikie

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

[llvm][NFC] Use c++17 style variable type traits

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: dblaikie

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

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

Fix incorrect usage of std::is_assignable.

We want to check that we can assign to an lvalue here, not a prvalue.

llvm-svn: 324152

Use std::forward to make ErrorOr<T> constructible from a value that has a user-defined conversion to T. No functionality change intended.

llvm-svn: 260196

Don't use std::errc.

As noted on Errc.h:

// * std::errc is just marked with is_error_condition_enum. This means that
// common patters like AnErrorCode == errc::no_such_file_or_directory take
//

Don't use std::errc.

As noted on Errc.h:

// * std::errc is just marked with is_error_condition_enum. This means that
// common patters like AnErrorCode == errc::no_such_file_or_directory take
// 4 virtual calls instead of two comparisons.

And on some libstdc++ those virtual functions conclude that

------------------------
int main() {
std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory);
return foo == std::errc::no_such_file_or_directory;
}
-------------------------

should exit with 0.

llvm-svn: 239683

show more ...

[Support] Fix ErrorOr equality operator.

llvm-svn: 237970

Ensure ErrorOr cannot implicitly invoke explicit ctors of the underlying type.

An unpleasant surprise while migrating unique_ptrs (see changes in
lib/Object): ErrorOr<int*> was implicitly convertibl

Ensure ErrorOr cannot implicitly invoke explicit ctors of the underlying type.

An unpleasant surprise while migrating unique_ptrs (see changes in
lib/Object): ErrorOr<int*> was implicitly convertible to
ErrorOr<std::unique_ptr<int>>.

Keep the explicit conversions otherwise it's a pain to convert
ErrorOr<int*> to ErrorOr<std::unique_ptr<int>>.

I'm not sure if there should be more SFINAE on those explicit ctors (I
could check if !is_convertible && is_constructible, but since the ctor
has to be called explicitly I don't think there's any need to disable
them when !is_constructible - they'll just fail anyway. It's the
converting ctors that can create interesting ambiguities without proper
SFINAE). I had to SFINAE the explicit ones because otherwise they'd be
ambiguous with the implicit ones in an explicit context, so far as I
could tell.

The converting assignment operators seemed unnecessary (and similarly
buggy/dangerous) - just rely on the converting ctors to convert to the
right type for assignment instead.

llvm-svn: 217048

show more ...

Finishing touch for the std::error_code transition.

While std::error_code itself seems to work OK in all platforms, there
are few annoying differences with regards to the std::errc enumeration.

Thi

Finishing touch for the std::error_code transition.

While std::error_code itself seems to work OK in all platforms, there
are few annoying differences with regards to the std::errc enumeration.

This patch adds a simple llvm enumeration, which will hopefully avoid build
breakages in other platforms and surprises as we get more uses of
std::error_code.

llvm-svn: 210920

show more ...

Use std::error_code instead of llvm::error_code.

The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace

Use std::error_code instead of llvm::error_code.

The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace. I will remove it shortly afterwards.

The cases where the general idea needed some tweaking:

* std::errc is a namespace in msvc, so we cannot use "using std::errc". I could
add an #ifdef, but there were not that many uses, so I just added std:: to
them in this patch.

* Template specialization had to be moved to the std namespace in this
patch set already.

* The msvc implementation of default_error_condition doesn't seem to
provide the same transformations as we need. Not too surprising since
the standard doesn't actually say what "equivalent" means. I fixed the
problem by keeping our old mapping and using it at error_code
construction time.

Despite these shortcomings I think this is still a good thing. Some reasons:

* The different implementations of system_error might improve over time.
* It removes 925 lines of code from llvm already.
* It removes 6313 bytes from the text segment of the clang binary when
it is built with gcc and 2816 bytes when building with clang and
libstdc++.

llvm-svn: 210687

show more ...

[C++11] Use 'nullptr'.

llvm-svn: 210442

[C++11] Remove LLVM_HAS_CXX11_STDLIB now that it is just on.

llvm-svn: 202587

Use LLVM_EXPLICIT instead of a function pointer as bool.

llvm-svn: 199437

Add a unit test for the copy constructor.

I would not normally add tests like these, but the copy constructor is not
used at all in our codebase with c++11, so having this tests might prevent
breaki

Add a unit test for the copy constructor.

I would not normally add tests like these, but the copy constructor is not
used at all in our codebase with c++11, so having this tests might prevent
breaking the c++03 build again.

llvm-svn: 198886

show more ...

Use getError and remove the error_code operator.

llvm-svn: 198799

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also com

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.

llvm-svn: 198685

show more ...

Simplify ErrorOr.

ErrorOr had quiet a bit of complexity and indirection to be able to hold a user
type with the error.

That feature is not used anymore. This patch removes it, it will live in svn
h

Simplify ErrorOr.

ErrorOr had quiet a bit of complexity and indirection to be able to hold a user
type with the error.

That feature is not used anymore. This patch removes it, it will live in svn
history if we ever need it again.

If we do need it again, IMHO there is one thing that should be done
differently: Holding extra info in the error is not a property a function also
returning a value or not. The ability to hold extra info should be in the error
type and ErrorOr templated over it so that we don't need the funny looking
ErrorOr<void>.

llvm-svn: 194030

show more ...

[Support][ErrorOr] Add support for implicit conversion from error code/condition enums.

llvm-svn: 176228

[Support][ErrorOr] Add support for convertable types.

Thanks to Andrew, David, and Aaron for helping fix this.

llvm-svn: 174552

Revert "[Support][ErrorOr] Add support for convertable types."

This reverts commit a33e1fafac7fedb1b080ef07ddf9ad6ddff3a830.

This unit test crashes on Darwon. It needs to be temporarily reverted
to

Revert "[Support][ErrorOr] Add support for convertable types."

This reverts commit a33e1fafac7fedb1b080ef07ddf9ad6ddff3a830.

This unit test crashes on Darwon. It needs to be temporarily reverted
to unblock the test infrastructure.

llvm-svn: 174458

show more ...

[Support][ErrorOr] Add support for convertable types.

llvm-svn: 174357

[Support][ErrorOr] Add optimized specialization of ErrorOr<void>.

ErrorOr<void> represents an operation that returns nothing, but can still fail.
It should be used in cases where you need the aditio

[Support][ErrorOr] Add optimized specialization of ErrorOr<void>.

ErrorOr<void> represents an operation that returns nothing, but can still fail.
It should be used in cases where you need the aditional user data that ErrorOr
provides over error_code.

llvm-svn: 173209

show more ...

ErrorOrTest.cpp: Check existence of EXPECT_DEBUG_DEATH. It is not always available.

llvm-svn: 173123