clangd stop in "parsing includes, running Build AST" for long time becase of bugprone-unchecked-optional-access

[findNextStep]

I found that Clangd often gets stuck in the 'parsing includes, running Build AST', and after using Mac's profile tool, I found that the actual stack is as follows

after disable bugprone-unchecked-optional-access in clangd configuration, every thing be ok.

I wonder if we can separately prompt for 'runing clang-tidy check xxxxx' instead of displaying 'parsing includes, running Build AST'

It is difficult to provide a minimum recurrence case because this problem occurs under a mountain of shit😂

[zyn0217]

after disable bugprone-unchecked-optional-access in clangd configuration, every thing be ok.

Speaking of bugprone-unchecked-optional-access, @HighCommander4, shall we consider making this check disabled by default in disableUnusableChecks, at least before clang-tidy works out llvm/llvm-project#55530?

[zyn0217]

I wonder if we can separately prompt for 'runing clang-tidy check xxxxx' instead of displaying 'parsing includes, running Build AST'

I don't think this is reasonable based on my limited knowledge of clangd and clang-tidy.

1. I presume each check in clang-tidy would be performed in a short period time thus users won't get clear hints most of the time.
2. It appears that clang-tidy doesn't offer any chance to signal progress, so producing checking details seems to be hard to implement.

However, I think it would be nice if there's an alternative to write the progress in the log for debugging purposes, if possible.

[findNextStep]

I wonder if we can separately prompt for 'runing clang-tidy check xxxxx' instead of displaying 'parsing includes, running Build AST'

I don't think this is reasonable based on my limited knowledge of clangd and clang-tidy.

1. I presume each check in clang-tidy would be performed in a short period time thus users won't get clear hints most of the time.
2. It appears that clang-tidy doesn't offer any chance to signal progress, so producing checking details seems to be hard to implement.

However, I think it would be nice if there's an alternative to write the progress in the log for debugging purposes, if possible.

just for error check, In most case parsing includes, running Build AST is also fast。

when we have many check, clang-tidy may be slow, and when clangd stop by clang-tidy, highlight is not work. make the situation confusing.

As I expect, clangd should work fine with highlight when process clang-tidy (maybe with out diagnostic)

[zyn0217]

just for error check, In most case parsing includes, running Build AST is also fast.

Yeah. But if we do emit detailed progress for each check, chances are that users would see text flickering in the status bar, which IMO is not a good UX design. (And I guess updating status rapidly might bring some harmful performance impact to editors.)

when we have many check, clang-tidy may be slow, and when clangd stop by clang-tidy, highlight is not work.

IIUC, language features like highlighting requires the AST for a .cpp file. Under the current translation unit scheduling model, we're running the clang-tidy in the AST building thread. Clang-tidy requires the AST built by clangd, which would surface the diagnostics from clang-tidy later.

(maybe with out diagnostic)

If we separate the clang-tidy from the AST thread, we'll need a synchronization mechanism to merge diagnostics from e.g., include-cleaner, clang-tidy, and clang. I don't think this is trivial to implement.

[sam-mccall]

Sounds like we should disable unchecked-optional-access as a slow check. In general dataflow-based checks are going to be slow sometimes, we should probably disable them until there's a real plan.

We could send a status update for "running tidy checks" potentially. We can't really indicate which, because their execution is interleaved: a single AST traversal reports matches for all checks as it finds them.

The flicker issue could be addressed by a denounce on the client or server, though we don't really have the thread infra to do it conveniently on the server and doing it on the client leaves the protocol chatty...

[HighCommander4]

Sounds like we should disable unchecked-optional-access as a slow check.

Agreed, a number of clangd users have run into issues with this checker (not just slowness but also crashes).

I do wonder if, before we add more checks to the list which are force-disabled as "unusable", we should first add the override mechanism discussed in #1337 (comment)? We have a contributor interested in implementing that mechanism, they're just waiting for a signal that it would be accepted -- @sam-mccall could you kindly weigh in on that?

[bwpge]

after disable bugprone-unchecked-optional-access in clangd configuration, every thing be ok.

Can confirm I am having the same issue that was resolved by disabling bugprone-unchecked-optional-access. I had a seemingly non-hallting execution mentioned in LLVM issue above (tried leaving vscode open for over an hour while I did other work, status never changed). I only stumbled across this thread last night because I very much prefer clangd to vscode's cpptools so I kept searching for some insight.

Working with Vulkan SDK, I thought my issue was the enormous generated headers (e.g., vulkan.hpp) and so I burned a few hours chasing the red herring of optimizing my includes with no improvement. Disabling this check in .clang-tidy this morning immediately resolved my issue.

I certainly don't have intimate knowledge of clangd, but I know a lot of users are going to be like me and copy a basic .clang-tidy from an established project without necessarily understanding every single check that gets executed. With no feedback from the status bar, and I didn't really understand how to read verbose logging output in the console, led me to disabling clangd -- it was the only way I could continue working on my project.

I would definitely appreciate some obvious (but opt-in) way to protect myself from my own ignorance :)

• Any mention of problematic checks on the main docs page (I had no idea this was a thing): https://clang.llvm.org/extra/clang-tidy/index.html
• Any log warning output on long running commands/tasks (say, >20 minutes) indicating there is probably an issue with configured checks
  • Could also suggest using a sanitized/basic .clang-tidy config to troubleshoot the problem
  • I only say this because as a complete novice I had no idea where to even start looking for troubleshooting tips on this issue
• Command line option such as --disable-slow-checks, which could then log which checks are being disabled
  • These could be more opinionated than the "unusable" checks that get disabled under the covers
  • This is also clearer that the user is picking speed over completeness/safety
• A "category" prefix or alias for slow/problematic checks so I can opt out of those (e.g., -problematic-* in my config)
  • Similar to above, this list can be more opinionated and is clearer the user is choosing to miss some stuff

Just spitballing with these suggestions, no idea on feasibility or if they're helpful.

Edit: my input above is conflating clangd with clang-tidy, which is not helpful. Sorry about that.