! In D55185#1330328, @nridge wrote:

Thanks!

So, on the clangd codebase, I got the following measurements for indexing with this patch compared to indexing without this patch:

 
- Size of index on disk increased by 3.2%
- Memory usage as reported by `dexp` increased by 3.6%

In D55044#1329604, @hokein wrote:
In fact, the existing modernize-make-unique can be configured to support absl::make_unique, you'd just need to configure the check option MakeSmartPtrFunction to absl::make_unique (this is what we do inside google).

See https://reviews.llvm.org/D52670#change-eVDYJhWSHWeW (the getModuleOptions() part) on how to do that

Thanks for the review.

In D55650#1329692, @kadircet wrote:

I think the description is misleading, you are saying that we were triggering an assertion and you are fixing that. But in reality, we were not triggering any assertions, this patch is adding the assertions right?

Keep the old behavior.

Please add a unittest for it, you can add it in unittests/clang-tidy/IncludeInserterTest.cpp.

In fact, the existing modernize-make-unique can be configured to support absl::make_unique, you'd just need to configure the check option MakeSmartPtrFunction to absl::make_unique (this is what we do inside google).

In D55185#1328011, @nridge wrote:

In D55185#1316564, @hokein wrote:

AFAIK, the symbol (section) is not the largest part of index (we have 30K symbols), would be interesting to know the (index, memory) size (including symbols in anonymous namespace).

Do you have a suggestion for how to measure memory usage? Should I just look at the memory usage of the clangd process in top?

Address review comment.

What are the cases we're trying to filter out? Only implicit constructor or anything else?

Update based on our offline discussion.

+ @hwright who have implemented a bunch of absl-duration-* checks, you might be interested in this as well.

The check looks good from my side, except one nit.

Update.

Forgot to associate this patch to the actual commit, committed in rL348475.

Address comments.

thanks!

Minor cleanup

Address review comments

• remove Unknown enum type
• make TUState only accessed by the worker thread.

In D55185#1316101, @nridge wrote:

This is a first attempt at a patch for this.

There are some cases this doesn't handle, which I was thinking of handling in follow-up commits (but we could do them here if desired):

• Entities in anonymous namespaces are still not indexed, There is a comment in SymbolCollector::shouldCollectSymbol() which says "Also we skip the symbols in anonymous namespace as the qualifier names of these symbols are like foo::<anonymous>::bar, which need a special handling." It's not clear to me how that should be handled, suggestions are welcome.

Using break.

Address comments and fix a bug in the test.

Fix nits.

Yeah, there are still modes where clangd behaves badly there. Note that the output from that pane is rarely useful anyway as clangd keeps producing errors about accessing non-open files, which would confuse people even more.
Overall we never designed this output to be readable by the users, so it's not really useful anyway. There are ways to communicate with the users in the protocol, we should be using them instead to be more user-friendly

In D55052#1312760, @ilya-biryukov wrote:

+1 to the change, this is annoying for me too.

In D55052#1312753, @hokein wrote:

@jfindley I'd like to understand how do these log messages noise you? Does the window prompt up to you automatically (this only happens when there is an error in clangd)? These messages only get print to the clangd-vscode output panel which is used for debugging purposes (normal users won't open this window by their own).

It's fine to have this open for debugging purposes, the real problem is that it pops up whenever clangd send an error response. We do this a lot now that we support cancellation and the default policy is to show an output window in that case as well.

@jfindley I'd like to understand how do these log messages noise you? Does the window prompt up to you automatically (this only happens when there is an error in clangd)? These messages only get print to the clangd-vscode output panel which is used for debugging purposes (normal users won't open this window by their own).

@ilya-biryukov, I hope the current patch is not too big for you to review, happy to chat offline if you want (sam and I had a lot of discussions before he is OOO).

• address review comments
• drop the LSP change, only focus on TUScheduler in this patch