Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The first iteration is D83831 but the diffs are clobbered and I can't change the history there :( So, creating a new one is maybe the best solution.
Tracer messages for sent and failed to parse items are not correct. Have to figure out how to print them _after_ the callback.
clang-tools-extra/clangd/index/remote/Client.cpp | ||
---|---|---|
61 | shouldn't we increment this before the continue above ? (or rename this to successful rather than received ?) | |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
42 | i think TraceFile is more appropriate here. | |
48 | is it only for pretty printing trace files? do we expect to have any other components this will interact in future? (if not maybe state that in the comments) | |
49 | this sounds like a debug feature, do we really want it to be true by default? | |
94 | all of this trickery is really nice. but i am not sure if it improves readability at all, from the perspective of call sites the amount of code is almost the same. moreover it was some trivial lambda before and instead it is lots of template parameters now. maybe just have templated function to replace the lambda body instead? e.g. template <typename StreamType, typenameResultType> void IndexCallback(Marshaller &M, StreamType &Item) { trace::Span Tracer....; auto SerializedSymbol = M.toProtobuf(Item); // log the events and much more ... } then call it in the callbacks. WDYT? |
Resolve most review comments.
clang-tools-extra/clangd/index/remote/Client.cpp | ||
---|---|---|
61 | Makes sense, I didn't think of "received" in terms of "overall" :P | |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
42 | TracerFile is what ClangdMain.cpp has; I'm not against this, but I think it'd be better to have them the same for consistency. WDYT? | |
48 | Yeah, right now it's only for trace files. It's quite possible that there will be something else that could be pretty-printed in the future, but not right now, so I changed description (specified trace files). | |
94 | I think this is a good idea but I can't think of a nice way to do that, too. IndexCallback would have to update Sent and FailedToSend (Tracer should be outside of the callback, right?), and the callback signature if fixed so I wouldn't be able to pass these parameters by reference :( I could probably make those two fields of the class but this doesn't look very nice, or pass member function (templated one) to the callback in each index request, but this also doesn't look very nice. I think the reason was initially to improve readability but then it's more about code deduplication: right now there are 3 pieces of code that do exactly the same, there will be a fourth one (relations request). Maybe readability even decreases but I really think that having 4 pieces of code with different types is not very nice. Also, D84525 compliments this and there will be practically only no functional code in the functions themselves. I can understand your argument and I partially support it but I really think we're unfortunately choosing between bad and worse. |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
---|---|---|
42 | (driveby, sorry) So my vote would be --trace or --trace-file or env CLANGD_TRACE=... | |
49 | This option is not worth having at all, IMO. | |
73 | you don't need both RequestT and ClangdRequest as template params:
| |
74 | StreamType doesn't need to be a type param as you can make the lambda param auto | |
75 | can't the return type just be auto? | |
94 | FWIW, I find the template to be very hard to read, and would prefer the version that is duplicated 4 times. I've left some suggestions for how to simplify (mostly, eliminating template parameters) but I'm still not sure it's worth it. | |
96 | I don't think you need forward here... just take the param by const reference? |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
---|---|---|
49 | Why not? It's relatively hard to read trace files otherwise. Do you think they should be pretty-printed by default? | |
96 | How do I do that? The problem is that some functions return bool and one void, so I can't really assign the result to variable and then return it. |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
---|---|---|
49 | FWIW, I've never had to read them except when initially developing/debugging the trace feature. I think either always-on or always-off is better than having a flag. | |
96 | Currently you have template <typename IndexCall>(IndexCall&& Call) { forward<IndexCall>(Call); } but I think this would work fine here: template <typename IndexCall>(const IndexCall& Call) { IndexCall(Call); } (nothing particularly wrong with this use of forward, but "more template goop" feels particularly expensive here. |
Resolve most review comments.
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
---|---|---|
73 |
Yeah this is the idea; I have D84525 for extending fromProtobuf so that it can be moved here. | |
75 | Ah, I thought LLVM is still C++ 11, not 14. Good to know, thanks! | |
96 | Ah, you meant passing the callback by const reference. I see, thanks for the suggestion! |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
---|---|---|
73 | Not doing this because of getting back to code duplication. |
thanks, LGTM apart from templated-lambdas.
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
---|---|---|
84 | usage of auto in here results in a templated-lambda. I don't think we want that (please let me know if I am missing something) maybe go back to using clangd::Symbol ? (same for other lambdas) | |
94 |
right, i've missed that bit. but I was suggesting you to call IndexCallback inside the lambda, e.g. callsites would look like this: Index->lookup(Req, [&](const auto &Item) { IndexCallback(*ProtobufMarshaller, Item); }); so in theory you could pass in Sent and FailedToSend as parameters to IndexCallback and mutate them in there. but not really relevant anymore. | |
206 | any reasons for not using elog in here (and in other places using llvm::errs() ? |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
---|---|---|
206 | I think we tend to use llvm::errs() instead of logs in CLI tools (ClangdMain.cpp and particularly TraceFile handling were the inspiration and it uses llvm::errs() although there are many elogs there, too) and I'm a little confused about when to use either of those. Could you explain how those are chosen in each case? |
shouldn't we increment this before the continue above ? (or rename this to successful rather than received ?)