Add expand_imports to resolve bare and except imports

[rodrigues]

Expands #4 to enable bare import resolution, if you think this path makes sense for ex_ast.

---

The bare-import fix left import Enum matching nothing: with no :only list there's no way to tell which local calls came from the import. This adds an opt-in expand_imports: true that loads the module and uses its real exports as the membership list, so a bare import Enum makes map(a, b) match Enum.map(_, _).

find_all(source, "Enum.map(_, _)")                       # 0
find_all(source, "Enum.map(_, _)", expand_imports: true) # 1

It also covers except:, which has the same problem — import Enum, except: [map: 2] only makes sense once we know the full export list, so it resolves to the exports minus the excluded names.

Functions the module defines itself shadow the import and are dropped, so a local def map/2 is never rewritten to Enum.map. When the module isn't loadable we fall back to no expansion.

Off by default; the extra export walk only runs for files that have a bare or except: import, so the common path is unaffected.

[dannote]

Thanks — this is a useful direction, and keeping it opt-in is the right default. I found a few correctness issues around import scope and only: :functions / only: :macros semantics that I think need changes before merge.

[dannote]

This currently makes expand_imports file-global: imports are collected once for the whole AST and then used while matching every node in the file.

I validated this false positive:

defmodule A do
  import Enum
  def run(list), do: map(list, & &1)
end

defmodule B do
  def run(list), do: map(list, & &1)
end

With expand_imports: true, Enum.map(_, _) matches both calls. The import from A leaks into sibling module B. I think this needs lexical/module scoping before the option is safe.

[dannote]

local_definitions(ast) is also file-global, so local shadowing can leak across sibling modules.

I validated this false negative:

defmodule A do
  def map(a, b), do: {a, b}
end

defmodule B do
  import Enum
  def run(list), do: map(list, & &1)
end

With expand_imports: true, Enum.map(_, _) returns no matches because A.map/2 suppresses expansion in B. Shadowing should be scoped to the module/function context where the call appears.

[dannote]

only: :functions and only: :macros collapse to :all, and expand_imports then resolves :all to functions + macros. That changes Elixir import semantics.

I validated both directions:

import ExAST.Query, only: :functions
where(query, expr)

incorrectly matches ExAST.Query.where(_, _), even though where/2 is a macro.

import ExAST.Query, only: :macros
from(pattern)

incorrectly matches ExAST.Query.from(_), even though from/1 is a function. We probably need to preserve whether the unresolved import is functions-only, macros-only, or both.

[rodrigues]

@dannote thanks for the review! Brought the edge cases into the tests, and made a few changes.

---

• Sibling leak: imports now carry the module they're declared in, and matching scopes them to the node's module path. A's import no longer reaches B, and a nested module still inherits an outer import.
• Local shadowing: locals are collected per module and resolved at match time against the call site, not file-wide. A.map/2 no longer suppresses the import in B. I also added a nested case — a local def shadows an outer import only inside its own module.
• only: :functions / :macros: these were collapsing to :all and resolving to both. They keep their kind now and resolve against just __info__(:functions) or __info__(:macros), so only: :functions won't match where/2 and only: :macros won't match from/1.

[dannote]

Thanks, the behavior issues look fixed now. Remaining blocker is CI: Credo flags ExAST.Pattern.imported_module/3 as nested too deep. Once that’s green, I’ll approve.