[llvm] Use value instead of getValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

Move llvm::array_lenghtof to llvm/ADT/STLArrayExtras.h

This moves the dependency of several files on include/llvm/ADT/STLExtras.h to
the much shorter llvm/ADT/STLArrayExtras.h

Differential Revision

Move llvm::array_lenghtof to llvm/ADT/STLArrayExtras.h

This moves the dependency of several files on include/llvm/ADT/STLExtras.h to
the much shorter llvm/ADT/STLArrayExtras.h

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

show more ...

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLEx

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat

show more ...

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no buil

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).

show more ...

Remove dependency from raw_ostream on <chrono>

The tryLockFor method from raw_fd_sotreamis the sole user of that
header, and it's not referenced in the mono repo. I still chose to keep
it (may be us

Remove dependency from raw_ostream on <chrono>

The tryLockFor method from raw_fd_sotreamis the sole user of that
header, and it's not referenced in the mono repo. I still chose to keep
it (may be useful for downstream user) but added a transient type that's
forward declared to hold the duration parameter.

Notable changes:

- "llvm/Support/Duration.h" must be included in order to use tryLockFor.
- "llvm/Support/raw_ostream.h" no longer includes <chrono>

This sole change has an interesting impact on the number of processed
line, as measured by:

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

before: 7917500
after: 7835142

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

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

[LTO] Fix assertion failed when flushing bitcode incrementally for LTO output.

In https://reviews.llvm.org/D86905, we introduce an optimization, when lld emits LLVM bitcode,
we allow bitcode writer

[LTO] Fix assertion failed when flushing bitcode incrementally for LTO output.

In https://reviews.llvm.org/D86905, we introduce an optimization, when lld emits LLVM bitcode,
we allow bitcode writer flush data to disk early when buffered data size is above some threshold.

But when `--plugin-opt=emit-llvm` and `-o /dev/null` are used,
lld will trigger assertion `BytesRead >= 0 && static_cast<size_t>(BytesRead) == BytesFromDisk`.
When we write output to /dev/null, BytesRead is zero, but at this program point BytesFromDisk is always non-zero.

Reviewed By: stephan.yichao.zhao, MaskRay

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

show more ...

Fixed some errors detected by PVS Studio

[llvm] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)

As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of rep

[llvm] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)

As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of report_fatal_error(const std::string&) with the Twine() variant which can be forward declared.

show more ...

[SystemZ][z/OS][Windows] Add new functions that set Text/Binary mode for Stdin and Stdout based on OpenFlags

On Windows, we want to open a file in Binary mode if OF_CRLF bit is not set. On z/OS, we

[SystemZ][z/OS][Windows] Add new functions that set Text/Binary mode for Stdin and Stdout based on OpenFlags

On Windows, we want to open a file in Binary mode if OF_CRLF bit is not set. On z/OS, we want to open a file in Binary mode if the OF_Text bit is not set.

This patch creates two new functions called ChangeStdinMode and ChangeStdoutMode which will take OpenFlags as an arg to determine which mode to set stdin and stdout to. This will enable patches like https://reviews.llvm.org/D100056 to not affect Windows when setting the OF_Text flag for raw_fd_streams.

Reviewed By: rnk

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

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

Frontend: Simplify handling of non-seeking streams in CompilerInstance, NFC

Add a new `raw_pwrite_ostream` variant, `buffer_unique_ostream`, which
is like `buffer_ostream` but with unique ownership

Frontend: Simplify handling of non-seeking streams in CompilerInstance, NFC

Add a new `raw_pwrite_ostream` variant, `buffer_unique_ostream`, which
is like `buffer_ostream` but with unique ownership of the stream it's
wrapping. Use this in CompilerInstance to simplify the ownership of
non-seeking output streams, avoiding logic sprawled around to deal with
them specially.

This also simplifies future work to encapsulate output files in a
different class.

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

show more ...

raw_ostream.cpp - remove duplicate includes. NFCI.

Remove headers already included in raw_ostream.h

Add raw_fd_stream that supports reading/seeking/writing

This is used by https://reviews.llvm.org/D86905 to support bitcode
writer's incremental flush.

[Support] Speedup llvm-dwarfdump 3.9x

Currently `strace llvm-dwarfdump x.debug >/tmp/file`:

ioctl(1, TCGETS, 0x7ffd64d7f340) = -1 ENOTTY (Inappropriate ioctl for device)
write(1, "

[Support] Speedup llvm-dwarfdump 3.9x

Currently `strace llvm-dwarfdump x.debug >/tmp/file`:

ioctl(1, TCGETS, 0x7ffd64d7f340) = -1 ENOTTY (Inappropriate ioctl for device)
write(1, " DW_AT_decl_line\t(89)\n"..., 4096) = 4096
ioctl(1, TCGETS, 0x7ffd64d7f400) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(1, TCGETS, 0x7ffd64d7f410) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(1, TCGETS, 0x7ffd64d7f400) = -1 ENOTTY (Inappropriate ioctl for device)

After this patch:

write(1, "0000000000001102 \"strlen\")\n "..., 4096) = 4096
write(1, "site\n DW_AT_low"..., 4096) = 4096
write(1, "d53)\n\n0x000e4d4d: DW_TAG_G"..., 4096) = 4096

The same speedup can be achieved by `--color=0` but that is not much convenient.

This implementation has been suggested by Joerg Sonnenberger.

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

show more ...

[Support] Class to facilitate file locking

This change define RAII class `FileLocker` and methods `lock` and
`tryLockFor` of the class `raw_fd_stream` to facilitate using file locks.

Differential R

[Support] Class to facilitate file locking

This change define RAII class `FileLocker` and methods `lock` and
`tryLockFor` of the class `raw_fd_stream` to facilitate using file locks.

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

show more ...

[Support] Don't tie errs() to outs() by default

This reverts part of D81156.

Accessing errs() concurrently was safe before and racy after D81156.
(`errs() << 'a'` is always racy)

Accessing outs()

[Support] Don't tie errs() to outs() by default

This reverts part of D81156.

Accessing errs() concurrently was safe before and racy after D81156.
(`errs() << 'a'` is always racy)

Accessing outs() and errs() concurrently was safe before and racy after D81156.

Don't tie errs() to outs() by default to fix the fallout.
llvm-dwarfdump is single-threaded and opting in the tie behavior is safe.

show more ...

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

[Support] Use outs() in ToolOutputFile

Summary:
If the output filename was specified as "-", the ToolOutputFile class
would create a brand new raw_ostream object referring to the stdout.
This patch

[Support] Use outs() in ToolOutputFile

Summary:
If the output filename was specified as "-", the ToolOutputFile class
would create a brand new raw_ostream object referring to the stdout.
This patch changes it to reuse the llvm::outs() singleton.

At the moment, this change should be "NFC", but it does enable other
enhancements, like the automatic stdout/stderr synchronization as
discussed on D80803.

I've checked the history, and I did not find any indication that this
class *has* to use a brand new stream object instead of outs() --
indeed, it is special-casing "-" in a number of places already, so this
change fits the pattern pretty well. I suspect the main reason for the
current state of affairs is that the class was originally introduced
(r111595, in 2010) as a raw_fd_ostream subclass, which made any other
solution impossible.

Another potential benefit of this patch is that it makes it possible to
move the raw_ostream class out of the business of special-casing "-" for
stdout handling. That state of affairs does not seem appropriate because
"-" is a valid filename (albeit hard to access with a lot of command
line tools) on most systems. Handling "-" in ToolOutputFile seems more
appropriate.

To make this possible, this patch changes the return type of
llvm::outs() and errs() to raw_fd_ostream&. Previously the functions
were constructing objects of that type, but returning a generic
raw_ostream reference. This makes it possible for new ToolOutputFile and
other code to use raw_fd_ostream methods like error() on the outs()
object. This does not seem like a bad thing (since stdout is a file
descriptor which can be redirected to anywhere, it makes sense to ask it
whether the writing was successful or if it supports seeking), and
indeed a lot of code was already depending on this fact via the
ToolOutputFile "back door".

Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

show more ...