You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The metadata builder currently expands calls to use, updating the Env to account for aliases made within a __using__ macro, which is great! However, the same thing does not appear to be done for other macros that may create aliases. This means we are unable to find the definition of functions for which the module was aliased in any macro besides __using__.
iex(1)>buffer="""defmodule MyCaller do import MyMacro my_alias Namespace.MyDep def call() do MyDep.my_function() # ^ endend"""iex(2)>ElixirSense.definition(buffer,6,14)nil
Does anyone see a reason we couldn't or shouldn't do the same thing for all macro calls? Would a pull request be welcome?
My motivation for this is that I'm working on an experimental dependency injection library that currently suffers from not being able to jump to the definition of functions belonging to injected modules. Addressing this seems like it would be one way to solve at least part of the problem.
The text was updated successfully, but these errors were encountered:
Well, it may be possible to expand more macros but it would require care. Please note that a lot of elixir keywords are macros and currently MatadataBuilder has special rules for them. The expansion should probably have lower priority than elixir keywords. Moreover, the AST after expansion is not like the standard elixir AST and doe's not alow for getting as much info as the standard one.
The mechanism is also quite fragile - see elixir-lsp/elixir-ls#193
Thank you for the info, it's much appreciated! I've got some other things to investigate before I can decide where to go with this, so I may or may not circle back later. I'll close the issue for now, but feel free to re-open if it's something you'd like to track.
The metadata builder currently expands calls to
use
, updating the Env to account for aliases made within a__using__
macro, which is great! However, the same thing does not appear to be done for other macros that may create aliases. This means we are unable to find the definition of functions for which the module was aliased in any macro besides__using__
.This is what currently works, given
my_code.ex
:As for what's lacking, note this very similar version of
my_code.ex
:Does anyone see a reason we couldn't or shouldn't do the same thing for all macro calls? Would a pull request be welcome?
My motivation for this is that I'm working on an experimental dependency injection library that currently suffers from not being able to jump to the definition of functions belonging to injected modules. Addressing this seems like it would be one way to solve at least part of the problem.
The text was updated successfully, but these errors were encountered: