feat: Elixir language support (.ex/.exs)

[w0lan]

Follow-up to #1220/#1221 and the Elixir entry in #648 — this adds Elixir as a supported language.

What this adds

• Modules as namespaces — defmodule, including nested modules with their full dotted name (Foo.Bar.Baz), defprotocol/defimpl blocks.
• Functions — def/defp/defmacro/defguard with correct visibility; multiple clauses of the same function (pattern matching, guards, default-arg heads) merge into one node. @spec becomes the signature, @doc/@moduledoc the docstring, defstruct the fields.
• Cross-module call edges — Module.fun(...) resolves through the file's alias table (including alias Foo.{A, B} and alias ..., as: X), __MODULE__.fun links within the module, &Mod.fun/arity captures and %Struct{} literals become references, @behaviour/use become implements, import/require/alias become import edges. Calls inside module-attribute values (@key Config.fetch!(...)) are extracted; @spec/@doc-style metadata attributes are consumed so String.t() and friends never become edges.
• Bare local calls resolve same-file only. In Elixir a bare lowercase call can only target the enclosing module or an import. Letting bare names fall through to repo-wide matching produced systematic false edges on real code (every Mix config :app, ... linked to someone's config/0; ConnTest's imported get(conn, path) linked to an HTTP client's get). The rule removed ~3.2k guessed edges on the first validation repo with zero recall cost on same-module calls. Import-based resolution is deliberately out of scope for v1.
• Silence over guessing — per the project's "a wrong edge is worse than no edge" rule, dynamic dispatch with no static target (variable receiver, apply/3, GenServer.call(pid, ...)) is left unlinked.

31 extraction/resolution tests added; full suite green (2393 passed / 0 failed on Node 22). The branch also went through two independent external code reviews before submission; all nine findings (guard-expression calls, %__MODULE__{} / &__MODULE__.fun/arity references, one-line defmodule ..., do: bodies, dynamically-named defmodule bodies — with static recovery of literal Module.concat(A, B) names, function-local alias, declaration/Kernel-macro call noise) were reproduced by a failing test first and are fixed in the last commit.

Validation on real code

Validated on 6 production Elixir repositories (~840 Elixir files) from one company codebase, deliberately spanning eras: Elixir ~1.4 (2017) → 1.15, plain Plug, Phoenix 1.4, Phoenix 1.7 + LiveView, Ecto 1–3, umbrella apps, and Elixir+TypeScript/JS mixed repos. Method as in #1220: grep-established ground truth vs graph for statically-resolvable calls (recall), manual audit of random calls edges (precision), plus a framework-macro false-edge sweep.

Metric	Result
Recall (statically-resolvable calls)	174/174 after the module-attribute fix (173/174 before)
Precision (random calls edges, manual audit)	60/60
False edges from Phoenix/Ecto/Mix macros	0
Same-named functions across modules (e.g. one name defined in 9 modules)	all resolved to the correct module

Results were uniform across the 1.4→1.15 spectrum — resolution rides on static module names (alias/fully-qualified), so old code works as well as new.

Fair coverage (methodology from the README table, calibrated by reproducing two published rows with the same build — requests 100.0% vs 100%, ripgrep 86.8% vs 86.7%): elixir-ecto/ecto 92.9% (52/56; the 4-file residual is all genuine frontier: the OTP application entry, compile-time conditional protocol impls, and the two query-DSL pseudo-modules Ecto.Query.API/WindowAPI). README row added in this PR. As an application-shaped stress test, the same measurement on plausible/analytics gives 67.4% on shipping Elixir — the residual there is structural (controllers/LiveView/workers reachable only through routing and scheduling; the router alone holds 419 unresolved refs because get/post/live macros don't bind their module argument), which is precisely what the Phoenix resolver below is for.

Known limitations (v1)

• Imported bare calls (import Foo + bare bar()) resolve same-file or not at all — no import expansion yet.
• Dynamic dispatch (module in a variable, apply/3, GenServer/process messaging, Application.get_env-configured modules) — intentionally silent.
• User macros / DSLs are not expanded (Phoenix router, Ecto schema DSL — see roadmap below), .heex templates are not parsed. This includes a bare module alias standing as a declarative-macro argument (field :secret, MyApp.EncryptedBinary, belongs_to :site, Site) — no reference is emitted for it yet (deliberate: emitting every capitalized mention risks noise; scoping it to known declarative positions is part of the Phoenix/Ecto follow-up).
• defdelegate does not yet emit an edge to its to: target; @derive does not emit an implements edge (its targets are almost always out-of-repo protocols like Jason.Encoder).
• A bare call in a file with two+ modules where both define the same name resolves to the first module (narrow; candidate fix is qualifying bare calls with the enclosing module).

Roadmap / follow-ups

This PR is the language core — the first step of a planned path:

1. Phoenix router resolver (src/resolution/frameworks/phoenix.ts) — route → controller action / LiveView edges (get "/x", StatsController, :funnel with scope-alias nesting), in the spirit of the Laravel/Rails resolvers. Next PR, in preparation; it will be registered in Tracking: framework-aware route & edge coverage requests #967. Measured headroom on plausible/analytics above; validation will run on production Phoenix apps plus a canonical OSS app + control, per the bar stated there.
2. .heex templates — component/assign references, precedent in docs/design/template-markup-parser.md.
3. Behaviour/GenServer callback edges — the dispatch-synthesizer family; after feedback on 1–2.

Relation to the open Elixir PRs (#228, #871, #1229, #1250)

This is an independent implementation — all four open PRs' code was read before submitting, and this section is meant to make consolidation easier, not to relitigate them. In one line each: #228 takes the same architectural approach as this PR (macro-name dispatch in a visitNode hook) with a narrower feature set; #871/#1250 are one lineage (#1250 = #871 rebased + an as:-alias fix, validated by its authors on a ~3,400-file production monorepo); #1229 pairs a thinner core with two genuinely valuable pieces no one else has — a tested Phoenix router resolver and HEEx handling.

What this PR adds over the extraction-focused ones (verified against #1250's branch):

• Default and multi-alias resolution. alias MyApp.Repo + Repo.get(...) and alias MyApp.Accounts.{User, Profile} resolve to the right module here (per-file alias table, memoized); in feat(extraction): Elixir language support (.ex/.exs) #1250 only the explicit alias X, as: Y form resolves — the import node is stored under the canonical name, so the common default-alias style yields no edge.
• Bare-call precision gate. feat(extraction): Elixir language support (.ex/.exs) #1250 has no Elixir rule in the name matcher, so bare lowercase calls fall through to repo-wide name matching — on the validation repos that produced systematic false edges (Mix config, imported ConnTest get). The same-file-only rule here removed ~3.2k guessed edges on the first validation repo.
• Attribute handling (@spec → signature, @doc → docstring, META vs custom attribute split so String.t() never becomes an edge but calls inside @key Config.fetch!(...) do), clause merging, defguard, protocol/impl blocks, captures and %Struct{} references.
• Validation methodology, in the spirit of PHP: method calls through a class property ($this->dep->method()) never resolve — constructor-injected dependencies produce no call edges #1220: ground truth established by grep per function (recall measured against what should be in the graph, not by inspecting what is), precision on random edge samples, and a framework-macro false-edge sweep — across 6 production repos + the calibrated fair-coverage measurement above. This is what caught the default-alias and bare-call classes in the first place.

@waseigo's #1229 (Phoenix resolver + HEEx) is complementary to this core and overlaps with follow-up 1 above — the router resolver there looks portable onto this core, and coordinating/crediting there beats duplicating it.

The branch is built on current main (no conflicts) with a clean, reviewable history — it's intended to be mergeable as-is. If you'd rather consolidate the Elixir PRs yourself (as with ArkTS/Nix), it works as the reference implementation + validation corpus too — take whatever is useful, same as #1221 — though the commits landing as they are would of course be the preferred outcome.

Scope adjustments or a different split are fine on request.

[w0lan]

While validating this branch on a production Elixir repo I noticed missing calls edges in ExUnit test modules (one module lost 9 of 26 calls to the same helper). It is not an extraction issue with this PR: since describe/test are macros rather than scopes, all N calls attribute to the enclosing module node, producing N refs with an identical (from_node, name, kind) key differing only by line/col — and extraction emits all of them correctly.

The loss happens later, in the resolver: when such a same-key group straddles the 5000-row resolution batch boundary, the per-batch cleanup (keyed on that 3-tuple, without line/col) deletes the whole group, including rows a later batch hasn't read yet. That's exactly #1265, fixed in #1266 — with #1266 applied on top of this branch, the repo goes from 17/26 to 26/26 edges for that module, with no other changes (+9 edges total, node count identical). Elixir test suites make this pre-existing bug much more likely to fire (many identical-key calls per module), so #1266 is worth landing alongside or before this PR.