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
* Address a FIXME by warning the user that both -run-synchronously and -j X are
passed.
* Fix a comment to suppress clang-tidy warning by passing the correct argument
name.
Reviewers: ioeric
Subscribers: ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43671
llvm-svn: 326051
The pthread solution here breaks standalone builds, which don't have the
relevant cmake magic for feature-detection.
The original reason for trying pthread was fear of libgcc without
support for thread_local (e.g. on the clang-x86_64-linux-selfhost-modules bot).
However the earliest supported GCC is 4.8, and this has __cxa_thread_atexit.
This will probably break that bot, it's not running a supported GCC and needs
to be upgraded. I'll try to find out how to do this.
llvm-svn: 324351
Summary:
thread_local has nice syntax and semantics, but requires __cxa_thread_atexit,
and some not-ancient runtime libraries don't provide it.
The clang-x86_64-linux-selfhost-modules buildbot is one example :-)
It works on windows, and the other platforms clang-tools-extra supports should
all have the relevant pthread API. So we just use that if it's available,
falling back to thread_local (so if a platform has neither, we'll fail to link).
The fallback should really be the other way, that would require cmake changes.
Reviewers: ilya-biryukov, bkramer
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42742
llvm-svn: 323949
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
Summary:
It will be used to pass around things like Logger and Tracer throughout
clangd classes.
Reviewers: sammccall, ioeric, hokein, bkramer
Reviewed By: sammccall
Subscribers: klimek, bkramer, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40485
llvm-svn: 320468
Chandler Carruth