(Optionally) don't follow symlinks

[sergei-dyshel]

I've noticed that ccls always resolves "real path" to referenced files by following symlinks. While there are certain advantages in this approach it may be undesirable in some cases.

For instance, I'm using symlinks to disguise real location of some system header files which are located in different places on my working machines. When I transfer database from one machine to another, ccs have to recompile the whole database because of "missing" header files.

I also believe a general argument: if files are referenced (in compile_commands.json or indirectly via include directives) with some symlink, there may be a reason for this and ccls should not be too smart and bypass this symlink by resolving the real location.

I think this behavior should be configurable. If author agrees, I may like to contribute a PR.

[MaskRay]

Long ago I had the idea that symlinks under the project root should not be followed while others (e.g. /usr/include/* headers) should be followed.

I'd like to understand what kind of configuration you want to make first.

[sergei-dyshel]

Ok, I'll try to be more specific.

I have a development server which has multiple versions of some library sitting in /MyLib-1/, /MyLib-2/ etc. I want my project to compile against specific version but I don't want to hardcode library path in compilation flags so I make a symlink /home/user/MyLib => /MyLib-2 and compile my project with -I /home/user/MyLib/include.

Now I want to transfer a database indexed by ccls to my laptop. For this purpose I take the specific version of MyLib I need and fetch it to /home/user/MyLib on my laptop. The rest of file paths are same on the server and laptop so ccls index should be valid on laptop.

But it doesn't work currently, because when indexing on server ccls resolves each file in /home/user/MyLib/include to it's real location inside /MyLib-2/include so upon opening the index on laptop it can not find this location so it have to reindex everything.

So you might say why not store /MyLib-1, /MyLib-2 on laptop too, but this might be not so easy if these libraries are part of some large directory structure which I don't need on laptop except for some header files needed by my project. So instead of partially recreating this directory structure I use symlinks which are universal UNIX solution for this kind of problems.

Now after I told you my case can you please explain your reasoning of following symlinks for system headers?

[MaskRay]

For a few system headers that can be references differently because of directory symlinks, tracing symlinks isn't bad, e.g. /usr/include/c++/8/algorithm /usr/include/c++/8.0.1/algorithm

That said, I agree with you that in most cases symlinks should not be followed.

ccls does not follow symlinks explicitly. What we see that Included files gett resolved is because

• indexer.cc IndexDataConsumer::handleDeclOccurence
• indexer.cc SeenFile
• clang_tu.cc PathFromFileEntry
• clang/Basic/FileManager.h tryGetRealPathName follows the symlink.

I think it may not easy not to follow symlinks.

[sergei-dyshel]

Actually I've managed to solve my case by disabling calls to tryGetRealPathName and llvm::sys::fs::real_path in the following locations:

• clang_tu.cc:PathFromFileEntry
• indexer.cc:GetFileLID

We can just make these calls optional.

[MaskRay]

It is a bit tricky. getName() is not very reliable, and in some occasions WorkingDir should be prepended. I need to dig a bit deeper with clang source code to understand it better.

You can try relative paths e.g. ../../../a.cc

[MaskRay]

See #314

[sergei-dyshel]

The solution in #314 only affects symlinked workspace directory and doesn't solve my problem of symlinked system headers or the general case I've described, right?

In that case please leave this issue open (for tracking purposes) or close it with some "WON'T DO" message.

[MaskRay]

See the description in #314.

close it with some "WON'T DO" message.

The clang label is for that purpose.