Captures @spec and @type ASTs at handler-compile time. Exposes them through the __rpc_specs__/0 and __rpc_types__/0 accessors.

Why this exists

RpcElixir.Router validates handler signatures inside __before_compile__. By default it reads specs from the handler's BEAM file. That path uses Code.Typespec.fetch_specs/1, which needs the BEAM on disk. Inside a single Mix project, the parallel compiler may run the router hook too early. In-progress handler BEAMs are not flushed yet. The result is a spurious "no @spec" error.

use RpcElixir.Handler avoids this. It captures the spec ASTs into a generated function. RpcElixir.Types.FromSpec prefers that accessor when it exists. The function call is also a compiler dependency edge. So the parallel compiler finishes the handler module first. The BEAM need not be on disk.

Without use, the framework still works. But the handler must then live in a separate Mix path: dep. Its BEAM lands on disk first that way.

RpcElixir.Router.expose/2 also requires it. Exposing a module reads its surface from __rpc_specs__/0, so a handler without use raises there.

Handler input arrives with atom keys. See RpcElixir.Types.validate/2. For a handler example, see Getting started.