Firstly, thanks for tackling this. It's quite an annoying issue, and our users would greatly benefit if it is addressed.

As for the fix itself, I'm not convinced this fixes the issue in all cases. As far as I understand, the bug is caused by a heuristic returning a false positive. What this PR does is change the heuristic based lookup to look inside a different list of comments - the one provided to the function rather than the one picked up through the search. What is to stop this from picking up false positives in other circumstances?

As far as I understand, the bug is caused by a heuristic returning a false positive. What this PR does is change the heuristic based lookup to look inside a different list of comments - the one provided to the function rather than the one picked up through the search. What is to stop this from picking up false positives in other circumstances?

Hm, let me explain how I see this all, and you can tell me if I'm missing something.

The bug is that when we request documentation for position P in file F but the symbol at position P doesn't have documentation, merlin pulls in comments from the last visited file A of some library and considers those comments as if they are in F, which I think is not what we want, so I removed the piece of code that's doing that.

• The list of comments passed to get_doc as an argument comments is the list of comments for the file from which we call the "find document" request.
• If this piece of code fails to find documentation, which is of course the case because the symbol at the given position P doesn't have documentation, the following code (that I removed) appends comments of the last visited file A to the comments of the current file F and tries to associate position P with the positions of the new list of comments (the association happens in Ocamldoc.associate_comment.)

To sum up, I think what's happening is when we fail to find documentation for position P in file F from other libs, we take the last visited file's docs and consider them as if they are in F.

Something I don't understand is why that code was there in the first place -- maybe there are cases when we do want that behavior.

@trefis, your input on this PR would also be appreciated :-)

This is one of the most frequently reported issues in ocaml-lsp. The most recent report was by craigfe