This is a refactoring: errors should be logged only on the highest level.
Switch from Optional to Expected in the serialization code.
Details
- Reviewers
kadircet - Commits
- rGfb5588b0ad59: [clangd] Propagate remote index errors via Expected
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
i think you might want to have an helper for creating stringerrors and use it in all places
clang-tools-extra/clangd/index/remote/Client.cpp | ||
---|---|---|
60 | elog already consumes the error | |
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp | ||
132 | error mentions definition too but conditional only looks for info and declaration? | |
159–160 | nit: swap branches and early exit, i.e. if(!SerializedHeader) { elog... continue; } push_back; | |
160–162 | what makes this a non-terminal error? | |
182–183 | nit: redundant braces | |
267–268 | again, what makes this non-terminal? | |
270 | elog already consumes the error | |
303–306 | is RelativePath user provided? can't we just assert on non-emptiness and non-absoluteness and make this function return a std::string instead? | |
318 | again why not make this (and the following) an assertion? | |
clang-tools-extra/clangd/index/remote/server/Server.cpp | ||
89 | nit: I would keep LookupRequest instead of going through descriptor()->name() (maybe even change the one in tracer), makes it more explicit especially for the people not experienced with protos. | |
94 | this still has auto in it? (and other callbacks too) | |
99 | again, elog consumes | |
123 | same for usage of descriptor()->name() | |
132 | again, elog consumes |
Haha, yeah I thought about that but then looked at other examples and saw that in some cases there are even more verbose calls :)
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp | ||
---|---|---|
303–306 | Could you elaborate on what you mean by user provided? Relative path is something that comes from the remote index. Ideally, this is non-empty and relative but I think the safer option is to maybe check for errors? Actually, I'm not sure about this but it's not user provided as in "given as a flag passed to CLI invocation by the end user". I think the point here is making errors recoverable and not shutting down the client, otherwise everything could be an assertion? Same in other places. WDYT? |
thanks, lgtm!
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp | ||
---|---|---|
303–306 |
Yes I was asking whether this comes from outside and ideally not processed at all before arriving at this logic.
Right, the safer is always to check for errors, but if we've already processed the RelativePath before it reaches this code path then there wouldn't be much value in spending more runtime checks (and also it would be callers responsibility generate the errors in such cases). I was asking this because I wasn't aware of the whole structure, but looks like this is literally the entry point (i.e. the first logic that verifies a user input) for path to uri conversions. So no action needed here. | |
clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp | ||
169 | i would ASSERT_TRUE here, as you'll end up crashing when fromProtoBuf returns an error (because you are not consuming the error and it is destroyed after completion of the statement). | |
418 | again should be ASSERT_TRUE for similar concerns stated above. | |
436 | again should be ASSERT_TRUE for similar concerns stated above. |
Good points, thanks!
Addressed post-LGTM comments.
clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp | ||
---|---|---|
303–306 | Yes, I agree that spending runtime on this is unfortunate but I guess it's the cost we'd have to pay :( |
elog already consumes the error