Add ms-specific missing header in Support/InitLLVM.cpp

[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] [Debuginfod] Move HTTPClient to Debuginfod library.

Following the discussion in D112753, this moves the HTTPClient from Support to Debuginfod library so that tools depending on Support do

[Support] [Debuginfod] Move HTTPClient to Debuginfod library.

Following the discussion in D112753, this moves the HTTPClient from Support to Debuginfod library so that tools depending on Support do not automatically depend on Curl as well. This also removes `HTTPClient::initialize()` and `HTTPClient::cleanup()` from `InitLLVM` so these steps should be implemented by user tools instead.

Reviewed By: phosek

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

show more ...

[llvm] [Support] Add CURL HTTP Client.

Provides an implementation of `HTTPClient` that wraps libcurl.

Reviewed By: dblaikie

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

[InitLLVM] Ensure SIGPIPE handler installed before sigaction()

The pipe signal handler must be installed before any other handlers are
registered. This is because the Unix RegisterHandlers function

[InitLLVM] Ensure SIGPIPE handler installed before sigaction()

The pipe signal handler must be installed before any other handlers are
registered. This is because the Unix RegisterHandlers function does not
perform a sigaction() for SIGPIPE unless a one-shot handler is present,
to allow long-lived processes (like lldb) to fully opt-out of llvm's
SIGPIPE handling and ignore the signal safely.

Fixes a bug introduced in D70277.

Tested by running Nick's test case:

% xcrun ./bin/clang -E -fno-integrated-cc1 x.c | tee foo.txt | head

I verified that child cc1 process exits with IO_ERR, and that the parent
recognizes the error code, exiting cleanly.

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

show more ...

llvm-ar: Fix MinGW compilation

llvm-ar is using CompareStringOrdinal which is available
only starting with Windows Vista (WINVER 0x600).

Fix this by hoising WindowsSupport.h, which sets _WIN32_WINN

llvm-ar: Fix MinGW compilation

llvm-ar is using CompareStringOrdinal which is available
only starting with Windows Vista (WINVER 0x600).

Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT
to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar.

Patch by Cristian Adam!

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

show more ...

[Signal] Allow llvm clients to opt into one-shot SIGPIPE handling

Allow clients of the llvm library to opt-in to one-shot SIGPIPE
handling, instead of forcing them to undo llvm's SIGPIPE handler
reg

[Signal] Allow llvm clients to opt into one-shot SIGPIPE handling

Allow clients of the llvm library to opt-in to one-shot SIGPIPE
handling, instead of forcing them to undo llvm's SIGPIPE handler
registration (which is brittle).

The current behavior is preserved for all llvm-derived tools (except
lldb) by means of a default-`true` flag in the InitLLVM constructor.

This prevents "IO error" crashes in long-lived processes (lldb is the
motivating example) which both a) load llvm as a dynamic library and b)
*really* need to ignore SIGPIPE.

As llvm signal handlers can be installed when calling into libclang
(say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for
SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the
current model.

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

show more ...

[Support] Move the static initializer install_out_memory_new_handler to InitLLVM

An application linking against LLVMSupport should not get the gratuitous
set::std_new_handler call.

Reviewed By: jfb

[Support] Move the static initializer install_out_memory_new_handler to InitLLVM

An application linking against LLVMSupport should not get the gratuitous
set::std_new_handler call.

Reviewed By: jfb

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

llvm-svn: 365915

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

Rename sys::Process::GetArgumentVector -> sys::windows::GetCommandLineArguments

GetArgumentVector (or GetCommandLineArguments) is very Windows-specific.
I think it doesn't make much sense to provide

Rename sys::Process::GetArgumentVector -> sys::windows::GetCommandLineArguments

GetArgumentVector (or GetCommandLineArguments) is very Windows-specific.
I think it doesn't make much sense to provide that function from sys::Process.

I also made a change so that the function takes a BumpPtrAllocator
instead of a SpecificBumpPtrAllocator. The latter is the class to call
dtors, but since char * is trivially destructible, we should use the
former class.

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

llvm-svn: 330216

show more ...

Define InitLLVM to do common initialization all at once.

We have a few functions that virtually all command wants to run on
process startup/shutdown. This patch adds InitLLVM class to do that
all at

Define InitLLVM to do common initialization all at once.

We have a few functions that virtually all command wants to run on
process startup/shutdown. This patch adds InitLLVM class to do that
all at once, so that we don't need to copy-n-paste boilerplate code
to each llvm command's main() function.

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

llvm-svn: 330046

show more ...