[NFC][TableGen] Adopt scaled indent in PredicateExpander (#109801)

Adopt scaled indent in PredicateExpander.
Added pre/post inc/dec operators to `indent` and related unit tests.
Verified by compar

[NFC][TableGen] Adopt scaled indent in PredicateExpander (#109801)

Adopt scaled indent in PredicateExpander.
Added pre/post inc/dec operators to `indent` and related unit tests.
Verified by comparing *.inc files generated by LLVM build with/without
the change.

show more ...

[Support] Add scaling support in `indent` (#109478)

Scaled indent is useful when indentation is always in steps of a fixed
number (the Scale) and still allow using the +/- operators to adjust
inde

[Support] Add scaling support in `indent` (#109478)

Scaled indent is useful when indentation is always in steps of a fixed
number (the Scale) and still allow using the +/- operators to adjust
indentation.

show more ...

[Support] Add helper struct `indent` for adding indentation (#108966)

Add helper struct indent() for adding indentation to raw_ostream.

[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial si

[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.

show more ...

[Support] Move raw_ostream::tie to raw_fd_ostream (#97396)

Originally, tie was introduced by D81156 to flush stdout before writing
to stderr. 030897523 reverted this due to race conditions. Nonethe

[Support] Move raw_ostream::tie to raw_fd_ostream (#97396)

Originally, tie was introduced by D81156 to flush stdout before writing
to stderr. 030897523 reverted this due to race conditions. Nonetheless,
it does cost performance, causing an extra check in the "cold" path,
which is actually the hot path for raw_svector_ostream. Given that this
feature is only used for errs(), move it to raw_fd_ostream so that it no
longer affects performance of other stream classes.

show more ...

[Support] Don't set "all_exe" mode by default for file written by llvm::writeToOutput

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

[STLExtras] Convert deref_or_none and zip_longest to std::optional

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the am

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

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

[llvm] Cleanup header dependencies in ADT and Support

The cleanup was manual, but assisted by "include-what-you-use". It consists in

1. Removing unused forward declaration. No impact expected.
2. R

[llvm] Cleanup header dependencies in ADT and Support

The cleanup was manual, but assisted by "include-what-you-use". It consists in

1. Removing unused forward declaration. No impact expected.
2. Removing unused headers in .cpp files. No impact expected.
3. Removing unused headers in .h files. This removes implicit dependencies and
is generally considered a good thing, but this may break downstream builds.
I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the
modification in the second part of the commit.
4. Replacing header inclusion by forward declaration. This has the same impact
as 3.

Notable changes:

- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h
- llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h
- llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h
- llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h

You may need to add some of these headers in your compilation units, if needs be.

As an hint to the impact of the cleanup, running

clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l

before: 8000919 lines
after: 7917500 lines

Reduced dependencies also helps incremental rebuilds and is more ccache
friendly, something not shown by the above metric :-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831

show more ...

[Support] No longer require flushing raw_string_ostream

Since 65b13610a5226b84889b923bae884ba395ad084d, raw_string_ostream
has been unbuffered by default, making .flush() a no-op. This diff
formaliz

[Support] No longer require flushing raw_string_ostream

Since 65b13610a5226b84889b923bae884ba395ad084d, raw_string_ostream
has been unbuffered by default, making .flush() a no-op. This diff
formalizes this by no longer .flush()ing in the .str() method or
the destructor. .str() has been marked as "consider removing", since
its primary use case used to be making .flush()+access a one-liner,
and it also has issues such as preventing NRVO/implicit move when used
in return statements.

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

show more ...

Support: Add closing namespace comment in raw_ostream_test.cpp, NFC

The closing namespace comment prevents clang-format from dropping a
blank line after the final test. Also add in a blank line (whi

Support: Add closing namespace comment in raw_ostream_test.cpp, NFC

The closing namespace comment prevents clang-format from dropping a
blank line after the final test. Also add in a blank line (which
simplifies merging/rebasing/etc. WIP patches).

show more ...

[llvm-objcopy][Support] move writeToOutput helper function to Support.

writeToOutput function is useful when it is necessary to create different kinds
of streams(based on stream name) and when we ne

[llvm-objcopy][Support] move writeToOutput helper function to Support.

writeToOutput function is useful when it is necessary to create different kinds
of streams(based on stream name) and when we need to use a temporary file
while writing(which would be renamed into the resulting file in a success case).
This patch moves the writeToStream helper into the Support library.

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

show more ...

Revert "[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream"

This reverts commit 7479a2e00bc41f399942e5106fbdf9b4b0c11506.

This commit causes compile errors on clang-x64-windows-ms

Revert "[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream"

This reverts commit 7479a2e00bc41f399942e5106fbdf9b4b0c11506.

This commit causes compile errors on clang-x64-windows-msvc, so I'm
reverting the patch for now.

For reference, the error in question is:

```
error C2280: 'llvm::raw_ostream_iterator<char,char>
&llvm::raw_ostream_iterator<char,char>::operator =(const
llvm::raw_ostream_iterator<char,char> &)': attempting to reference a deleted
function

note: compiler has generated 'llvm::raw_ostream_iterator<char,char>::operator ='
here

note: 'llvm::raw_ostream_iterator<char,char>
&llvm::raw_ostream_iterator<char,char>::operator =(const
llvm::raw_ostream_iterator<char,char> &)': function was implicitly deleted
because 'llvm::raw_ostream_iterator<char,char>' has a data member
'llvm::raw_ostream_iterator<char,char>::OutStream' of reference type
```

show more ...

[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream

Adds a class `raw_ostream_iterator` that behaves like
std::ostream_iterator, but can be used with raw_ostream.
This is useful for

[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream

Adds a class `raw_ostream_iterator` that behaves like
std::ostream_iterator, but can be used with raw_ostream.
This is useful for using raw_ostream with std algorithms.

For example, it can be used to output std containers as follows:

```
std::vector<int> V = { 1, 2, 3 };
std::copy(V.begin(), V.end(), raw_ostream_iterator<int>(outs(), ", "));
// Output: "1, 2, 3, "
```

The API tries to follow std::ostream_iterator as closely as is
practically possible.

Reviewed By: dblaikie, mkitzan

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

show more ...

[Support] Add reserve() method to the raw_ostream.

If resulting size of the output stream is already known,
then the space for stream data could be preliminary
allocated in some cases. f.e. raw_stri

[Support] Add reserve() method to the raw_ostream.

If resulting size of the output stream is already known,
then the space for stream data could be preliminary
allocated in some cases. f.e. raw_string_ostream could
preallocate the space for the target string(it allows
to avoid reallocations during writing into the stream).

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

show more ...

[Support][unittest] Fix asan failure after D81156

[Support] Add stream tie function and use it for errs()

errs() is now tied to outs() so that if something prints to errs(),
outs() will be flushed before the printing occurs. This avoids
interleavin

[Support] Add stream tie function and use it for errs()

errs() is now tied to outs() so that if something prints to errs(),
outs() will be flushed before the printing occurs. This avoids
interleaving output between the two and is consistent with standard cout
and cerr behaviour.

Reviewed by: labath, JDevlieghere, MaskRay

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

show more ...

[Support] Move color handling from raw_fd_ostream to raw_ostream

Move the color handling code from raw_fd_ostream to raw_ostream. This
makes it possible to use colors with any ostream when enabled.

[Support] Move color handling from raw_fd_ostream to raw_ostream

Move the color handling code from raw_fd_ostream to raw_ostream. This
makes it possible to use colors with any ostream when enabled. The
existing behavior where only raw_fd_ostream supports colors by default
remains unchanged.

Differential revision: https://reviews.llvm.org/D81110

show more ...

raw_ostream_test: Add a missing buffer flush

Default raw_string_ostream to be unbuffered

raw_string_ostream can just use the std::string as a buffer. The buffer
requirement came from the days when the minimum buffer size was 128
(fixed in 2015

Default raw_string_ostream to be unbuffered

raw_string_ostream can just use the std::string as a buffer. The buffer
requirement came from the days when the minimum buffer size was 128
(fixed in 2015) and std::string was non-SSO. Now we can just use the
inline capacity for small things and on a good growth strategy later.

This assumes that the standard library isn't doing something bad like
only growing to the exact size. I checked some common implementations
and they grow by 2x (libc++) or 1.5x (msvc) which is reasonable. We
should still check if this incurs any performance regressions though.

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

Implement LWG#1203 for raw_ostream.

Implement LWG#1203 (https://cplusplus.github.io/LWG/issue1203) for raw_ostream
like libc++ does for std::basic_ostream<...>.

Add a operator<< overload that takes

Implement LWG#1203 for raw_ostream.

Implement LWG#1203 (https://cplusplus.github.io/LWG/issue1203) for raw_ostream
like libc++ does for std::basic_ostream<...>.

Add a operator<< overload that takes an rvalue reference of a typed derived from
raw_ostream, streams the value to it and returns the stream of the same type as
the argument.

This allows free operator<< to work with rvalue reference raw_ostreams:
raw_ostream& operator<<(raw_ostream&, const SomeType& Value);
raw_os_ostream(std::cout) << SomeType();

It also allows using the derived type like:
auto Foo = (raw_string_ostream(buffer) << "foo").str();

Author: Christian Sigg <csigg@google.com>
Differential Revision: https://reviews.llvm.org/D70686

show more ...

Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFC

F_{None,Text,Append} are kept for compatibility since r334221.

llvm-svn: 367800

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