aboutsummaryrefslogtreecommitdiff
path: root/docs/dev-docs/issues/the-mod-pathfinder.md
diff options
context:
space:
mode:
author魏曹先生 <1992414357@qq.com>2026-07-09 20:32:59 +0800
committer魏曹先生 <1992414357@qq.com>2026-07-09 20:57:24 +0800
commit9b8deaeced4f4a6f7c2492528019cc6e10c379ac (patch)
tree992600b808a2ce51712752596fc193898f819239 /docs/dev-docs/issues/the-mod-pathfinder.md
parent39724ff4d6e4e2fdd8b476077523e251ad686780 (diff)
docs: restructure dev-docs sidebar and move pages into subdirectories
Diffstat (limited to 'docs/dev-docs/issues/the-mod-pathfinder.md')
-rw-r--r--docs/dev-docs/issues/the-mod-pathfinder.md64
1 files changed, 0 insertions, 64 deletions
diff --git a/docs/dev-docs/issues/the-mod-pathfinder.md b/docs/dev-docs/issues/the-mod-pathfinder.md
deleted file mode 100644
index 5f8c902..0000000
--- a/docs/dev-docs/issues/the-mod-pathfinder.md
+++ /dev/null
@@ -1,64 +0,0 @@
-<h1 align="center">The Mod Pathfinder</h1>
-<p align="center">
- A build-time analyzer that computes full module paths for Mingling types, resolving path ambiguity in macros.
-</p>
-
-## Background
-
-Currently, `gen_program!` requires all involved types to be `use`d within their module. Mingling lacks a complete module path analyzer — waiting for `proc-macro-span` to stabilize is clearly not practical, so a solution for obtaining module paths is needed.
-
-## Solution
-
-We plan to create an analyzer called `mingling-mod-pathf`, enabled via Mingling's `"pathf"` feature, to compute the full paths of all defined Mingling types.
-
-### Behavior When Enabled
-
-**`mingling_core`**: If the `builds` feature is enabled, introduces the `mingling::build::analyze_and_build_type_mapping()` method (analysis completed at Build-Time)
-
-**`mingling_macros`**: Modifies the behavior of the `gen_program!()` macro — automatically loads the mapping table from the analysis file generated by `mingling::build::analyze_and_build_type_mapping()`, and directly uses the full `mod::path` instead of `TypeName` (injected at Compile-Time)
-
-## Challenges
-
-`mingling-mod-pathf` needs to understand **all** Mingling syntax features.
-Fortunately, Mingling's type creation is almost always explicit:
-
-```rust
-mod sub {
- mingling::macros::pack!(ResultMyName = String); // directly creates ..::sub::ResultMyName
-}
-```
-
-There are a few exceptions, such as the implicit Dispatcher provided by `extra_macros`, but these can be inferred from the node name:
-
-```rust
-dispatcher!("remote.add"); // although the type is unknown, we can infer CMDRemoteAdd and EntryRemoteAdd
-```
-
-And also `#[program_setup]`:
-
-```rust
-#[program_setup] // can infer CustomSetup from the function name `custom_setup`
-fn custom_setup(program: &mut Program<ThisProgram>) {
- program.with_dispatchers((CMD1, CMD2, CMD3, CMD4, CMD5));
-}
-```
-
-## Pathf Output Format
-
-Uses TOML key-value pairs, formatted as follows:
-
-```toml
-ResultRemoteAdd = "crate::mymod::ResultRemoteAdd"
-```
-
-Recommended storage location is under the target directory:
-
-```
-/target/{target}/{crate-name}/type-mapping.toml
-```
-
-## Other Issues
-
-This solution is limited to Mingling's own syntax system. If types like `dispatcher!`, `pack!` are indirectly expanded through macros, the analyzer will not be able to discover them.
-
-However, this approach solves the current main pain points, so this issue can be set aside for now and addressed later.