feat(engine): support shorthand notation inside ~H sigil #278
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The full-module notation (`<MyMod.button>`) was already supported in "go to definition", because when passed to ElixirSense, it correctly recognized the form and found the appropriate module and the function. However, with a shorthand notation it was not so simple, because `.button` is not valid Elixir and ElixirSense was not able to make anything of it. This implements the support for shorthand notation by doing a preliminary step before sending the code to ElixirSense. It modifies the AST and the Document of ForgeAnalysis and replaces all the calls to `<.button>` with `< button(assigns)` so that ElixirSense can correctly interpret it as a local function call with arity 1. This works for functions defined in the same module, but also for imported functions. Support for ending tag is also included. While this might seem as a hacky solution, it makes handling shorthand notation as close as possible to handling the full-module notation, making sure these two stay conceptually close.
The testing happens in Engine and there the presence of LiveView is mocked.
katafrakt
changed the title
doorgan
reviewed
Jan 2, 2026
Collaborator
doorgan
left a comment
doorgan
left a comment
There was a problem hiding this comment.
Thank you!
This is working, I only have some minor comments so far. One thing I could not get to work was Hover, I get logs saying the entity was resolved to the right thing, but no hover docs show.
Another note but I think this is more of an ElixirSense issue, I get the logs spammed with this sometimes when I trigger go to definition:
18:44:25.258 [warning] ** (RuntimeError) ~H requires a variable named "assigns" to exist and be set to a map
(phoenix_live_view 0.20.7) lib/phoenix_component.ex:791: Phoenix.Component."MACRO-sigil_H"/3
(xp_elixir_sense 2.0.0) lib/elixir_sense/core/normalized/macro/env.ex:54: anonymous fn/5 in XPElixirSense.Core.Normalized.Macro.Env.wrap_expansion/7
(xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:2144: XPElixirSense.Core.Compiler.expand_macro_callback/7
(xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:117: XPElixirSense.Core.Compiler.expand/3
(xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:2055: XPElixirSense.Core.Compiler.expand_macro/7
(xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:117: XPElixirSense.Core.Compiler.expand/3
(xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:2165: XPElixirSense.Core.Compiler.expand_macro_callback/7
(xp_elixir_sense 2.0.0) lib/elixir_sense/core/compiler.ex:117: XPElixirSense.Core.Compiler.expand/3
| end | ||
|
|
||
| defp phoenix_component_available? do | ||
| Code.ensure_loaded?(Phoenix.Component) |
Collaborator
There was a problem hiding this comment.
We probably want Engine.Module.Loader.ensure_loaded? here. Code.ensure_loaded?/1 can be quite slow, so we have a cache for it
Suggested change
| Code.ensure_loaded?(Phoenix.Component) | |
| Engine.Module.Loader.ensure_loaded?(Phoenix.Component) |
| # (i.e., phoenix_live_view is in the dependencies). | ||
| @spec maybe_normalize(Analysis.t(), Position.t()) :: Analysis.t() | ||
| def maybe_normalize(analysis, position) do | ||
| if phoenix_component_available?() do |
Collaborator
There was a problem hiding this comment.
If possible, I think we also need to check in the analysis scopes if sigil_H from Phoenix.Component is imported
Comment on lines
+49
to
+53
| |> Zipper.zip() | ||
| |> Zipper.find(&(&1 == sigil)) | ||
| |> case do | ||
| nil -> analysis.ast | ||
| zipper -> zipper |> Zipper.replace(new_sigil) |> Zipper.root() |
Collaborator
There was a problem hiding this comment.
In case we need to speed this up for large files, there's also Sourceror.FastZipper
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #269
The full-module notation (
<MyMod.button>) was already supported in "go to definition", because when passed to ElixirSense, it correctly recognized the form and found the appropriate module and the function. However, with a shorthand notation it was not so simple, because.buttonis not valid Elixir and ElixirSense was not able to make anything of it.This implements the support for shorthand notation by doing a preliminary step before sending the code to ElixirSense. It modifies the AST and the Document of ForgeAnalysis and replaces all the calls to
<.button>with< button(assigns)so that ElixirSense can correctly interpret it as a local function call with arity 1. This only happens whenphoenix_live_viewis added as a dependency1.This works for functions defined in the same module, but also for imported functions. Support for ending tag is also included.
While this might seem as a hacky solution, it makes handling shorthand notation as close as possible to handling the full-module notation, making sure these two stay conceptually close.
Footnotes
I looked into making a more detailed check here, basically checking if
Phoenix.Componentis imported into current module, but there's just too many ways to do so. I don't think the code analysis can do that, we would need to actually compile the code (using ElixirSense?). But I settled for a much simpler condition in this case. ↩