Details
Diff Detail
- Repository
- rCTE Clang Tools Extra
Event Timeline
clangd/Quality.cpp | ||
---|---|---|
373 | is 2 really enough? | |
clangd/Quality.h | ||
98 | you've inserted in the middle of the file proximity stuff :-) | |
98 | Generally we'd put both context/symbol types as the signal here, rather than just whether they match, unless it's prohibitive. They'd get populated manually, and by merge() overloads, respectively. |
- Increase the multiplier
- Move the member out of the file proximity group
clangd/Quality.cpp | ||
---|---|---|
373 | Changed to 5. We can tweak it later if that turns out to be too big. | |
clangd/Quality.h | ||
98 | I did it to avoid inefficiencies of:
My understanding is that (1) can be avoided by storing a reference to a type, since it outlives the signals. That's probably not a bottleneck anyway, but keeping it a bool flag for now and happy to change it to your liking. |
clangd/CodeComplete.cpp | ||
---|---|---|
1307–1308 | Here would be a good place to include the expected type in a log message | |
1521 | This is too verbose for vlog... could be dlog but I'm not sure it's actually needed in the end, we have code completion signal dumps. You should update Quality.cpp so the new signal is included :-) | |
clangd/Quality.h | ||
98 | Agree with your analysis. I think our goal here should be to have a model with small # of per-symbol types, and small size of each type, so the per-symbol copy would be cheap. Sequencing is tricky - we don't have that optimization yet. Can we replay a session with some code completion and see if it shows up in a profiler? (Perfect would be one type per symbol, types are 8-byte hashes. Unfortunately I think pointer->base conversions mean symbols must admit multiple tokens. But I have some ideas...) |
clangd/Quality.h | ||
---|---|---|
98 | After discussing offline, we ended up with a bunch of flags to indicate whether:
Let me know if that look ok. The bit that I don't like is that they're computed ad-hoc outside the merge function, which is a bit ugly. |
Here would be a good place to include the expected type in a log message