Skip to content
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

Closed
KornelH opened this issue Jul 14, 2021 · 1 comment · Fixed by #1394
Closed

Sym links are not followed #1064

KornelH opened this issue Jul 14, 2021 · 1 comment · Fixed by #1394
Labels
bug Something isn't working

Comments

@KornelH
Copy link

KornelH commented Jul 14, 2021

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 the include_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:

.
├── build_generated
│   └── group_a
│       └── mylib
│           └── gen
│               └── include
│                   └── person.hrl
└── under_version_control
    ├── build_generated -> ../build_generated
    ├── erlang_ls.config
    └── group_a
        └── mylib
            ├── include
            │   └── vehicle.hrl
            └── src
                ├── mylib.app.src
                └── mylib.erl

Files are very simple, under_version_control/group_a/mylib was generated by command rebar3 new lib and removed the not relevant files.

person.hrl:

-record(person, {
        name :: string()
        }).

vehicle.hrl:

-record(vehicle, {
        type :: atom(),
        passengers,
        color = "red"
        }).

mylib.erl:

-module(mylib).

-export([f/0]).

-include("person.hrl").
-include("vehicle.hrl").

f() ->
    [#person{name = "Paul McCartney"},
     #vehicle{type = submarine,
              passengers = 4,
              color = "yellow"}
    ].

erlang_ls.config:

otp_path: "<_path_to_>/otp"
apps_dirs:
  - "group_a/*"
diagnostics:
  disabled:
    - crossref
    - dialyzer
    - elvis
include_dirs:
  - "group_a/*/include"
  - "build_generated/group_a/mylib/gen/include"
lenses:
  enabled:
    - server-info
  disabled:
    - ct-run-test
    - show-behaviour-usages

Please find the complete example attached as erlang_ls_dont_follow_symlinks.tar.gz.

If build_generated is symlinked from under under_version_control then in file mylib.erl I get an error messages:

  • "can't find include file "person.hrl"" at line -include("person.hrl"). and
  • "record person undefined" at record usage.

If I copy build_generated under under_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.27
  • Editor used: Visual Studio Code 1.58.0 on Windows 10, Remote Development to Ubuntu 16.04 LTS
  • LSP client used: erlang-ls/vscode v0.0.27
@KornelH KornelH added the bug Something isn't working label Jul 14, 2021
@robertoaloi
Copy link
Member

Thanks for the detailed report @KornelH , seems related to #1046 .

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
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants