As originally reported here: ocamllabs/vscode-ocaml-platform#2059
Like many Linux users, several subdirectories of my $HOME are symbolic links to directories that live on a separate data partition. This is used to keep a consistent workspace across distros. This also means that every file in my OCaml project has two separate paths which alias to the same file; for example:
~/src/tlaplus/proofs/src/tlapm_lib.ml/mnt/data/src/tlaplus/proofs/src/tlapm_lib.ml
A good correctness criterion here is that all paths should resolve to ~/ paths instead of /mnt paths if operating from a ~/ context, which is what VS Code and other editors do for opening files when launched inside the ~/ path. Resolving a path to a /mnt/ path generally results in buggy behavior, which I will document here.
This LSP generally works well, except for two cases I've found: go-to-definition, and find-all-references. These work for OCaml files within the same subdirectory, but fails when going outside of that subdirectory. Consider the following project structure, which will be used to explain the problem:
/
└── src/
├── tlapm_lib.ml
└── sany/
├── sany.ml
└── xml.ml
Go-to-definition
When executing go-to-definition on a symbol defined in xml.ml from sany.ml, go-to-definition works perfectly: xml.ml is opened at the appropriate definition, using a ~/ prefix. However, when executing go-to-definition on a symbol defined in sany/sany.ml from tlapm_lib.ml, sany.ml is opened with the /mnt prefix. This is arguably not inherently a bug, although editor plugins (for example, neovim) find it confusing to have multiple buffers open that alias to the same file.
Find-all-references
For ~/ prefixes, find-all-references only works for files within the same subdirectory. When executing find-all-references on a definition in xml.ml, it will correctly find the uses within sany.ml. However, when executing find-all-references on a definition in sany.ml, it will not find the uses within tlapm_lib.ml. This is definitely a bug.
When sany.ml is opened with the /mnt prefix (for example by running go-to-definition from tlapm_lib.ml), running find-all-references on the same symbol in sany.ml correctly finds the usage in tlapm_lib.ml.
This isn't my first time encountering development tooling issues when using symlinked directories (see vscode-neovim/vscode-neovim#2284) so maybe I should just abandon this practice.
As originally reported here: ocamllabs/vscode-ocaml-platform#2059
Like many Linux users, several subdirectories of my
$HOMEare symbolic links to directories that live on a separate data partition. This is used to keep a consistent workspace across distros. This also means that every file in my OCaml project has two separate paths which alias to the same file; for example:~/src/tlaplus/proofs/src/tlapm_lib.ml/mnt/data/src/tlaplus/proofs/src/tlapm_lib.mlA good correctness criterion here is that all paths should resolve to
~/paths instead of/mntpaths if operating from a~/context, which is what VS Code and other editors do for opening files when launched inside the~/path. Resolving a path to a/mnt/path generally results in buggy behavior, which I will document here.This LSP generally works well, except for two cases I've found: go-to-definition, and find-all-references. These work for OCaml files within the same subdirectory, but fails when going outside of that subdirectory. Consider the following project structure, which will be used to explain the problem:
Go-to-definition
When executing go-to-definition on a symbol defined in
xml.mlfromsany.ml, go-to-definition works perfectly:xml.mlis opened at the appropriate definition, using a~/prefix. However, when executing go-to-definition on a symbol defined insany/sany.mlfromtlapm_lib.ml,sany.mlis opened with the/mntprefix. This is arguably not inherently a bug, although editor plugins (for example, neovim) find it confusing to have multiple buffers open that alias to the same file.Find-all-references
For
~/prefixes, find-all-references only works for files within the same subdirectory. When executing find-all-references on a definition inxml.ml, it will correctly find the uses withinsany.ml. However, when executing find-all-references on a definition insany.ml, it will not find the uses withintlapm_lib.ml. This is definitely a bug.When
sany.mlis opened with the/mntprefix (for example by running go-to-definition fromtlapm_lib.ml), running find-all-references on the same symbol insany.mlcorrectly finds the usage intlapm_lib.ml.This isn't my first time encountering development tooling issues when using symlinked directories (see vscode-neovim/vscode-neovim#2284) so maybe I should just abandon this practice.