[PATCH] D116713: [clangd] Support configuration of inlay hints.
Sam McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Jan 7 15:04:17 PST 2022
sammccall added inline comments.
================
Comment at: clang-tools-extra/clangd/InlayHints.cpp:51
bool VisitCXXConstructExpr(CXXConstructExpr *E) {
+ if (!Cfg.InlayHints.DeducedTypes)
+ return true;
----------------
hokein wrote:
> this should be `!Cfg.InlayHints.ParameterNames`.
>
> What do you think the idea of moving guards deeper (`processCall` and `addTypeHint`)? The code seems clearer and we don't have to add them in all Visit* implementation, this means that we pay cost of running some necessary code, but I think it is trivial and probably worthy.
I agree where to put the checks is an annoying question (and worth minimizing, since I've managed to get two wrong already).
I do think there needs to be a pattern so we don't accidentally skip checks.
- Easest is to postfilter (check in addInlayHint). That *does* hurt performance. Debug build on my laptop is ~170ms for all hints, ~160ms for postfilter with all categories disabled, ~5ms for current impl (prefilter) with all categories disabled. (On SemaCodeComplete.cpp, just eyeballing traces)
- Checking in VisitXXX methods (as done here) is a very regular pattern. Downside is you need many checks, and you can forget/break one
- Checks in helpers so that one is always hit (as you propose) touches fewer places but it's ad-hoc. I'm afraid of getting it wrong as the impl is modified (missing checks, doing too much work first, etc).
- Splitting RAV per category is an interesting option. Checking is very elegant, nicer code structure, can trace per-category latency, disabled categories can't crash... The downside is extra overhead, but this must be <5ms in the performance above. We can still choose to bundle simple categories together...
I think I'll do as you propose for now, improve the tests, and refactor to try to make it feel less ad-hoc later.
Also I should work out what we're spending 170ms on... EDIT: it turns out it's just assembling JSON objects :-\
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D116713/new/
https://reviews.llvm.org/D116713
More information about the cfe-commits
mailing list