summaryrefslogtreecommitdiffstats
path: root/clang-tools-extra/clangd/TUScheduler.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [clangd] Replace UniqueFunction with llvm::unique_function.Benjamin Kramer2018-07-031-14/+17
| | | | | | One implementation of this ought to be enough for everyone. llvm-svn: 336228
* [clangd] Fix a data race in TUSchedulerIlya Biryukov2018-06-281-5/+5
| | | | | | | | | | By recomputing CompilerInvocation instead of copying it. The problem was caused by the fact that copies of CompilerInvocation store references to the shared state (DiagnosticOptions) when copied, causing data races when two different copies are destroyed from different threads. llvm-svn: 335836
* [clangd] Compute better estimates for memory usage of the ASTIlya Biryukov2018-06-011-1/+1
| | | | | | | Also fix the return value of IdleASTs::getUsedBytes(). It was 'bool' instead of 'size_t' *facepalm*. llvm-svn: 333758
* [clangd] Attempt the fix the buildbots after r333737Ilya Biryukov2018-06-011-1/+4
| | | | llvm-svn: 333742
* [clangd] Keep only a limited number of idle ASTs in memoryIlya Biryukov2018-06-011-51/+197
| | | | | | | | | | | | | | | | | | | | | | | Summary: After this commit, clangd will only keep the last 3 accessed ASTs in memory. Preambles for each of the opened files are still kept in memory to make completion and AST rebuilds fast. AST rebuilds are usually fast enough, but having the last ASTs in memory still considerably improves latency of operations like findDefinition and documeneHighlight, which are often sent multiple times a second when moving around the code. So keeping some of the last accessed ASTs in memory seems like a reasonable tradeoff. Reviewers: sammccall Reviewed By: sammccall Subscribers: malaperle, arphaman, klimek, javed.absar, ioeric, MaskRay, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D47063 llvm-svn: 333737
* [clangd] Build index on preamble changes instead of the AST changesIlya Biryukov2018-05-241-3/+3
| | | | | | | | | | | | | | | | | | | | | Summary: This is more efficient and avoids data races when reading files that come from the preamble. The staleness can occur when reading a file from disk that changed after the preamble was built. This can lead to crashes, e.g. when parsing comments. We do not to rely on symbols from the main file anyway, since any info that those provide can always be taken from the AST. Reviewers: ioeric, sammccall Reviewed By: ioeric Subscribers: malaperle, klimek, javed.absar, MaskRay, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D47272 llvm-svn: 333196
* [clangd] Don't expose vfs in TUScheduler::runWithPreamble.Ilya Biryukov2018-03-141-9/+14
| | | | | | | | | | | | | | | | Summary: It was previously an easy way to concurrently access a mutable vfs, which is a recipe for disaster. Reviewers: sammccall Reviewed By: sammccall Subscribers: klimek, jkorous-apple, cfe-commits, ioeric Differential Revision: https://reviews.llvm.org/D44463 llvm-svn: 327537
* [clangd] Revamp handling of diagnostics.Ilya Biryukov2018-03-121-9/+8
| | | | | | | | | | | | | | | | Summary: The new implementation attaches notes to diagnostic message and shows the original diagnostics in the message of the note. Reviewers: hokein, ioeric, sammccall Reviewed By: sammccall Subscribers: klimek, mgorny, cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D44142 llvm-svn: 327282
* [clangd] Debounce streams of updates.Sam McCall2018-03-021-25/+72
| | | | | | | | | | | | | | | | | | | Summary: Don't actually start building ASTs for new revisions until either: - 500ms have passed since the last revision, or - we actually need the revision for something (or to unblock the queue) In practice, this avoids the "first keystroke results in diagnostics" problem. This is kind of awkward to test, and the test is pretty bad. It can be observed nicely by capturing a trace, though. Reviewers: hokein, ilya-biryukov Subscribers: klimek, jkorous-apple, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D43648 llvm-svn: 326546
* [clangd] BindWithForward -> Bind. NFCSam McCall2018-02-231-6/+5
| | | | llvm-svn: 325868
* Fix "not all control paths return a value" MSVC warning. NFCI.Simon Pilgrim2018-02-221-0/+1
| | | | llvm-svn: 325802
* [clangd] Allow embedders some control over when diagnostics are generated.Sam McCall2018-02-221-42/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Through the C++ API, we support for a given snapshot version: - Yes: make sure we generate diagnostics for exactly this version - Auto: generate eventually-consistent diagnostics for at least this version - No: don't generate diagnostics for this version Eventually auto should be debounced for better UX. Through LSP, we force diagnostics for initial load (bypassing future debouncing) and all updates follow the "auto" policy. This is complicated to implement under the CancellationFlag design, so rewrote that part to just inspect the queue instead. It turns out we never pass None to the diagnostics callback, so remove Optional from the signature. The questionable behavior of not invoking the callback at all if CppFile::rebuild fails is not changed. Reviewers: ilya-biryukov Subscribers: klimek, jkorous-apple, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D43518 llvm-svn: 325774
* [clangd] Tracing: name worker threads, and enforce naming scheduled async tasksSam McCall2018-02-191-30/+55
| | | | | | | | | | | | | | | | | | | Summary: This has a bit of a blast radius, but I think there's enough value in "forcing" us to give names to these async tasks for debugging. Guessing about what multithreaded code is doing is so unfun... The "file" param attached to the tasks may seem to be redundant with the thread names, but note that thread names are truncated to 15 chars on linux! We'll be lucky to get the whole basename... Reviewers: ilya-biryukov Subscribers: klimek, jkorous-apple, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D43388 llvm-svn: 325480
* [clangd] Stop exposing Futures from ClangdServer operations.Sam McCall2018-02-131-11/+38
| | | | | | | | | | | | | | | | | | | | Summary: LSP has asynchronous semantics, being able to block on an async operation completing is unneccesary and leads to tighter coupling with the threading. In practice only tests depend on this, so we add a general-purpose "block until idle" function to the scheduler which will work for all operations. To get this working, fix a latent condition-variable bug in ASTWorker, and make AsyncTaskRunner const-correct. Reviewers: ilya-biryukov Subscribers: klimek, jkorous-apple, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D43127 llvm-svn: 324990
* [clangd] Remove threading-related code from ClangdUnit.hIlya Biryukov2018-02-091-24/+34
| | | | | | | | | | | | Reviewers: sammccall, hokein, ioeric Reviewed By: sammccall Subscribers: klimek, jkorous-apple, cfe-commits Differential Revision: https://reviews.llvm.org/D43065 llvm-svn: 324725
* Resubmit "[clangd] The new threading implementation"Ilya Biryukov2018-02-081-66/+361
| | | | | | | | | | | Initially submitted as r324356 and reverted in r324386. This change additionally contains a fix to crashes of the buildbots. The source of the crash was undefined behaviour caused by std::future<> whose std::promise<> was destroyed without calling set_value(). llvm-svn: 324575
* Revert "[clangd] The new threading implementation" (r324356)Ilya Biryukov2018-02-061-358/+60
| | | | | | | | | | | | And the follow-up changes r324361 and r324363. These changes seem to break two buildbots: - http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/14091 - http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules-2/builds/16001 We will need to investigate what went wrong and resubmit the changes afterwards. llvm-svn: 324386
* [clangd] The new threading implementationIlya Biryukov2018-02-061-60/+358
| | | | | | | | | | | | | | | | | | Summary: In the new threading model clangd creates one thread per file to manage the AST and one thread to process each of the incoming requests. The number of actively running threads is bounded by the semaphore to avoid overloading the system. Reviewers: sammccall Reviewed By: sammccall Subscribers: klimek, mgorny, jkorous-apple, ioeric, hintonda, cfe-commits Differential Revision: https://reviews.llvm.org/D42573 llvm-svn: 324356
* [clangd] Pass Context implicitly using TLS.Sam McCall2018-01-311-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [clangd] Refactored threading in ClangdServerIlya Biryukov2018-01-311-0/+124
Summary: We now provide an abstraction of Scheduler that abstracts threading and resource management in ClangdServer. No changes to behavior are intended with an exception of changed error messages. This patch is preliminary work to allow a revamped threading implementation that will move the threading code out of CppFile. Reviewers: sammccall, bkramer, jkorous-apple Reviewed By: sammccall Subscribers: hokein, mgorny, hintonda, ioeric, jkorous-apple, cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D42174 llvm-svn: 323851
OpenPOWER on IntegriCloud