After FuzzyFindRequest JSON (de)serialization was introduced, it should replace ad-hoc fuzzy-find request parsing implemented in the IndexBenchmark driver.
Details
Diff Detail
Event Timeline
clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp | ||
---|---|---|
21 | We don't need the usings, just shorten the name on usage sites (usages are inside namespace clangd) | |
36–38 | Maybe read a JSON array from the file instead? Pros: we get valid json, can have prettified forms too. |
@ilya-biryukov thanks! I was assuming that the StringRef constructor parses user-provided string :(
llvm::json::Array is used now.
clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp | ||
---|---|---|
65 | I thought that this should panic instead of returning empty Requests: otherwise it wouldn't be possible to detect problems in the benchmark driver in test, for example (it will just run benchmark over empty list of requests instead of doing something useful). |
clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp | ||
---|---|---|
65 | Let's "panic" explicitly, e.g. with exit(1). |
clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp | ||
---|---|---|
65 | Good point; fixed! |
clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp | ||
---|---|---|
47 | If there was a json parsing error, we should consume it and print to the user, i.e. llvm::errs() << "Error when parsing json requests file: " << llvm::toString(std::move(JSONArray)); The user-facing error when an object is not an array should probably be a separate one. | |
64 | Check for return value of fromJSON and also report an error if it failed? |
clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp | ||
---|---|---|
48 | We should only call takeError() when JSONArray is an error. Not an array value should be handled separately. BTW, can we add tests with invalid inputs for both of these cases? | |
60 | Maybe also output the request that failed to parse? |
We don't need the usings, just shorten the name on usage sites (usages are inside namespace clangd)