[PATCH] D48687: [clangd] Avoid duplicates in findDefinitions response

Simon Marchi via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 27 17:08:16 PDT 2018


simark created this revision.
Herald added subscribers: cfe-commits, jkorous, MaskRay, ioeric, ilya-biryukov.

When compile_commands.json contains some source files expressed as
relative paths, we can get duplicate responses to findDefinitions.  The
responses only differ by the URI, which are different versions of the
same file:

  "result": [
      {
          ...
          "uri": "file:///home/emaisin/src/ls-interact/cpp-test/build/../src/first.h"
      },
      {
          ...
          "uri": "file:///home/emaisin/src/ls-interact/cpp-test/src/first.h"
      }
  ]

In getAbsoluteFilePath, we try to obtain the realpath of the FileEntry
by calling tryGetRealPathName.  However, this doesn't work for
FileEntries that don't actually open the file, because their
RealPathName field is never populated.

I changed getAbsoluteFilePath so that if tryGetRealPathName returns an
empty string, we try to find the real path using VFS.getRealPath.  This
requires to pass the VFS all the way from ClangdServer.

I tried to write a test case similar to

  TEST(GoToDefinition, RelPathsInCompileCommand)

that would trigger this issue, but I wasn't able to.  No matter what I
do, the paths are returned by the FileManager as already normalized /
without the "..".  There must be something different in the test case
than in real execution that I don't see.

Repro instructions are in bug #37963, though I can include them in the
commit message if you prefer.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D48687

Files:
  clangd/ClangdServer.cpp
  clangd/XRefs.cpp
  clangd/XRefs.h
  unittests/clangd/TestTU.cpp
  unittests/clangd/TestTU.h
  unittests/clangd/XRefsTests.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D48687.153209.patch
Type: text/x-patch
Size: 7278 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20180628/be2f5caa/attachment-0001.bin>


More information about the cfe-commits mailing list