sammccall added a comment. In D113268#3111995 <https://reviews.llvm.org/D113268#3111995>, @mstorsjo wrote:
>> I think the biggest testing problem we have though is that we don't have a >> good way of defining integration tests with paths set up the right way >> (since we can't really use absolute paths in our tests, and most of our bugs >> involve comparing absolute paths). > > Yup, I can totally understand that. And as I haven't tested clangd in this > setup other than the unit tests, I'm not sure if it works entirely in > practice though - with other unit tests in Clang I've seen lots of cases > where e.g. paths aren't considered as in the same directory when paths are > expressed with different separators. > > For someone unfamiliar with the tool, is there a simple "smoke test > procedure" I could try out with it to kick the tyres? There's `clangd --check=some_file.cc` which simulates opening up a file in an editor and clicking around in it. It does require a `compile_command.json` in a parent directory to know about build flags. To try it out for real you need to connect an editor to it with a plugin (like vscode-clangd). But realistic problems with paths tend to come from interactions with external sources. For example, we had a bug that involved: - vscode sending paths like `file://c:/test.cc` (lowercase C), which made its way into our AST cache - cmake creating `compile_commands.json` like `C:\test.cc` (uppercase C), which made its way into our index - when renaming a symbol, results from the two weren't deduplicated against each other so the edit was applied twice > Anyway, I'll have a look at the seemingly odd/fragile change and get back to > you on that. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113268/new/ https://reviews.llvm.org/D113268 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
