summaryrefslogtreecommitdiffstats
path: root/clang-tools-extra/unittests/clangd/TraceTests.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [clangd] Move clangd tests to clangd directory. check-clangd is no longer ↵Sam McCall2019-04-291-127/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | part of check-clang-tools. Summary: Motivation: - this layout is a pain to work with - without a common root, it's painful to express things like "disable clangd" (D61122) - CMake/lit configs are a maintenance hazard, and the more the one-off hacks for various tools are entangled, the more we see apathy and non-ownership. This attempts to use the bare-minimum configuration needed (while still supporting the difficult cases: windows, standalone clang build, dynamic libs). In particular the lit.cfg.py and lit.site.cfg.py.in are merged into lit.cfg.in. The logic in these files is now minimal. (Much of clang-tools-extra's lit configs can probably be cleaned up by reusing lit.llvm.llvm_config.use_clang(), and every llvm project does its own version of LDPATH mangling. I haven't attempted to fix any of those). Docs are still in clang-tools-extra/docs, I don't have any plans to touch those. Reviewers: gribozavr Subscribers: mgorny, javed.absar, MaskRay, jkorous, arphaman, kadircet, jfb, cfe-commits, ilya-biryukov, thakis Tags: #clang Differential Revision: https://reviews.llvm.org/D61187 llvm-svn: 359424
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [clangd] Remove 'using namespace llvm' from .cpp files. NFCIlya Biryukov2019-01-071-15/+16
| | | | | | | | The new guideline is to qualify with 'llvm::' explicitly both in '.h' and '.cpp' files. This simplifies moving the code between header and source files and is easier to keep consistent. llvm-svn: 350531
* [clangd] Namespace style cleanup in cpp files. NFC.Sam McCall2018-10-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Standardize on the most common namespace setup in our *.cpp files: using namespace llvm; namespace clang { namespace clangd { void foo(StringRef) { ... } And remove redundant llvm:: qualifiers. (Except for cases like make_unique where this causes problems with std:: and ADL). This choice is pretty arbitrary, but some broad consistency is nice. This is going to conflict with everything. Sorry :-/ Squash the other configurations: A) using namespace llvm; using namespace clang; using namespace clangd; void clangd::foo(StringRef); This is in some of the older files. (It prevents accidentally defining a new function instead of one in the header file, for what that's worth). B) namespace clang { namespace clangd { void foo(llvm::StringRef) { ... } This is fine, but in practice the using directive often gets added over time. C) namespace clang { namespace clangd { using namespace llvm; // inside the namespace This was pretty common, but is a bit misleading: name lookup preferrs clang::clangd::foo > clang::foo > llvm:: foo (no matter where the using directive is). llvm-svn: 344850
* Fix misuse of llvm::YAML in clangd test.Jordan Rose2018-03-231-1/+1
| | | | | | Caught by LLVM r328345! llvm-svn: 328354
* [clangd] Fix tracing now that spans lifetimes can overlap on a thread.Sam McCall2018-02-151-3/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: The chrome trace viewer requires events within a thread to strictly nest. So we need to record the lifetime of the Span objects, not the contexts. But we still want to show the relationship between spans where a context crosses threads, so do this with flow events (i.e. arrows). Before: https://photos.app.goo.gl/q4Dd9u9xtelaXk1v1 After: https://photos.app.goo.gl/5RNLmAMLZR3unvY83 (This could stand some further improvement, in particular I think we want a container span whenever we schedule work on a thread. But that's another patch) Reviewers: ioeric Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits Differential Revision: https://reviews.llvm.org/D43272 llvm-svn: 325220
* [clangd] Pass Context implicitly using TLS.Sam McCall2018-01-311-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Modify the Span API so that Spans propagate with contexts.Sam McCall2018-01-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This is probably the right behavior for distributed tracers, and makes unpaired begin-end events impossible without requiring Spans to be bound to a thread. The API is conceptually clean but syntactically awkward. As discussed offline, this is basically a naming problem and will go away if (when) we use TLS to store the current context. The apparently-unrelated change to onScopeExit are because its move semantics broken if Func is POD-like since r322838. This is true of function pointers, and the lambda I use here that captures two pointers only. I've raised this issue on llvm-dev and will revert this part if we fix it in some other way. Reviewers: ilya-biryukov Subscribers: klimek, jkorous-apple, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D42499 llvm-svn: 323511
* [clangd] Implemented tracing using ContextIlya Biryukov2017-12-141-3/+5
| | | | | | | | | | | | Reviewers: sammccall, ioeric, hokein Reviewed By: sammccall Subscribers: klimek, luckygeck, cfe-commits Differential Revision: https://reviews.llvm.org/D40488 llvm-svn: 320706
* [clangd] Tracing improvementsSam McCall2017-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: [clangd] Tracing improvements Compose JSON using JSONExpr Allow attaching metadata to spans (and avoid it if tracing is off) Attach IDs and responses of JSON RPCs to their spans The downside is that large responses make the trace viewer sluggish. We should make our responses less huge :-) Or fix trace viewer. Reviewers: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40132 llvm-svn: 318928
* Fix clangd test on platforms where get_thread_name does nothing.Sam McCall2017-11-021-2/+10
| | | | llvm-svn: 317194
* Performance tracing facility for clangd.Sam McCall2017-11-021-0/+120
Summary: This lets you visualize clangd's activity on different threads over time, and understand critical paths of requests and object lifetimes. The data produced can be visualized in Chrome (at chrome://tracing), or in a standalone copy of catapult (http://github.com/catapult-project/catapult) This patch consists of: - a command line flag "-trace" that causes clangd to emit JSON trace data - an API (in Trace.h) allowing clangd code to easily add events to the stream - several initial uses of this API to capture JSON-RPC requests, builds, logs Example result: https://photos.app.goo.gl/12L9swaz5REGQ1rm1 Caveats: - JSON serialization is ad-hoc (isn't it everywhere?) so the API is limited to naming events rather than attaching arbitrary metadata. I'd like to fix this (I think we could use a JSON-object abstraction). - The recording is very naive: events are written immediately by locking a mutex. Contention on the mutex might disturb performance. - For now it just traces instants or spans on the current thread. There are other things that make sense to show (cross-thread flows, non-thread resources such as ASTs). But we have to start somewhere. Reviewers: ioeric, ilya-biryukov Subscribers: cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D39086 llvm-svn: 317193
OpenPOWER on IntegriCloud