# Rust Support in Maguyva: Safe Context for AI-Assisted Changes

Canonical source: https://maguyva.ai/languages/rust

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Maguyva supports Rust with AST parsing and symbol extraction so AI agents can navigate modules, impl blocks, constructors, and dependency paths before changing strict, safety-oriented code.

## Support snapshot

- Tier: AST and symbol support
- Programming
- Extensions: .rs
- Real AST parsing for syntax-aware search and structural context.
- Named symbols feed semantic lookup and cross-reference. Graph navigation is available when relationship extraction is enabled.
- This language contributes symbols and relationships to graph-aware search; supported edge types vary with its native constructs.
- AST parsing and symbol extraction are both available.

## Best fit

- Systems, platform, or CLI repositories where Rust is chosen because correctness and change safety actually matter.
- Teams that want AI help exploring a Rust codebase before editing ownership-sensitive or low-level logic.
- Repos where modules, generated types, macros, and surrounding tooling make one-file reasoning unreliable.

## Agent workflows

- Trace where a struct or component is constructed before changing its behavior.
- Compare module patterns and implementation shapes instead of inventing a new one.
- Find the paths that depend on a type or helper before asking the agent to refactor it.

## Why Rust changes need more than autocomplete

Rust is one of the clearest cases where AI should navigate first and edit second. The language is usually chosen because correctness matters, not because the team wants more speculative change generation. So the standard for "Rust support" should be high: can the agent understand module boundaries, impl blocks, concrete type construction, and surrounding context before it proposes a refactor?

That is the real value threshold. Syntax generation is not the interesting part.

## What Maguyva actually extracts in Rust

Maguyva captures Rust functions and implementation blocks as distinct structural concepts, and it treats struct expressions as real instantiations. That gives the graph a useful view of where concrete types are built, not just where they are named.

The config also filters a large amount of macro and stdlib noise, which is important in Rust because macro-heavy code can otherwise swamp the graph with things that are technically valid calls but not very helpful when you are trying to understand repository behavior.

## Useful MCP workflows for Rust repos

The most useful starting patterns are:

- `find_symbol` for the struct, enum, or module-owned function you are about to change.
- `dependency_search` before refactoring a core type, so you know which code paths depend on it.
- `get_task_context` for conceptual prompts like "trace retry logic around the HTTP client" when the path crosses multiple modules.

## Where this page is most relevant

Use this page if you want AI assistance in Rust without giving up the cautious workflow that makes Rust worth using. If the repo is more service-oriented than systems-oriented, [Go](/languages/go) is the closer comparison. If Rust is only one surface in a larger estate, the mixed-language story on the [stack page](/stack) matters more than the parser checklist.

## Engine details

- `impl_item` and `function_item` are captured distinctly, which helps separate concrete functions from implementation blocks.
- Struct expressions count as instantiations, so the graph can follow where types are actually constructed.
- Macros and common stdlib constructors are aggressively filtered so the relationship graph stays focused on repository code.

## Useful MCP entry points

- `find_symbol`: Start with the struct, enum, or module-owned function you care about and expand from there.
- `dependency_search`: Use it before touching a core type or module to see inbound usage, not just local references.
- `get_task_context`: Useful when the task is conceptual, such as tracing retry logic or resource lifecycles across modules.