-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sym links are not followed #1064
Labels
bug
Something isn't working
Comments
the-mikedavis
added a commit
to the-mikedavis/erlang_ls
that referenced
this issue
Oct 24, 2022
…_paths/2` erlang-ls#346 discarded any paths containing symlinks since they broke assumptions about there being a single URI for each module in calls to `els_utils:find_module/1`. erlang-ls#648 added prioritization for cases when there are multiple URIs in `els_utils:find_module/1`, so discarding paths with symlinks is now no longer necessary. Following symlinks is necessary when using rebar3 checkout dependencies (erlang-ls#1046) or when using Bazel (erlang-ls#1064) since Bazel places dependencies and compiled files under its cache directory and symlinks the relevant directory in the cache to the workspace directory. This change removes the behavior of `els_utils:resolve_paths/2` that discards paths containing symlinks.
robertoaloi
pushed a commit
that referenced
this issue
Nov 8, 2022
#346 discarded any paths containing symlinks since they broke assumptions about there being a single URI for each module in calls to `els_utils:find_module/1`. #648 added prioritization for cases when there are multiple URIs in `els_utils:find_module/1`, so discarding paths with symlinks is now no longer necessary. Following symlinks is necessary when using rebar3 checkout dependencies (#1046) or when using Bazel (#1064) since Bazel places dependencies and compiled files under its cache directory and symlinks the relevant directory in the cache to the workspace directory. This change removes the behavior of `els_utils:resolve_paths/2` that discards paths containing symlinks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Some build systems (e.g. Bazel) places generated files outside of the workspace/project/repository and symlink those one way or another (e.g. Bazel creates a symlink
bazel-bin
from the workspace). Erlang header files could be generated there therefore I add those directories to theinclude_dirs
configuration, e.g.bazel-bin/.../inclulde
. Erlang-ls doesn't recognize the HRL files in these generated and linked directories.To Reproduce
I created a dummy setup like below:
Files are very simple,
under_version_control/group_a/mylib
was generated by commandrebar3 new lib
and removed the not relevant files.person.hrl:
vehicle.hrl:
mylib.erl:
erlang_ls.config:
Please find the complete example attached as erlang_ls_dont_follow_symlinks.tar.gz.
If
build_generated
is symlinked from underunder_version_control
then in filemylib.erl
I get an error messages:-include("person.hrl").
andIf I copy
build_generated
underunder_version_control
instead of symlinking then everything works perfectly.Expected behavior
Follow include directories even if those are symlinks.
Actual behavior
Symlinks are not followed, HRL files reside in symlinked include directories are not found.
Context
erlang_ls
version (tag/sha): I don't know, I use erlang-ls/vscode v0.0.27The text was updated successfully, but these errors were encountered: