What happens
src/manifest_modules.rs is declared as a module twice, so the compiler builds two independent copies of it. One copy is reachable and runs; the other is dead. Every dead-code warning the file produces describes the copy nobody calls, which leaves the live copy with no dead-code signal at all.
The two declarations
src/main.rs:44:
src/manifest.rs:13-14:
#[path = "manifest_modules.rs"]
mod manifest_modules;
The #[path] attribute points the second declaration at the same file, so it compiles as crate::manifest::manifest_modules alongside crate::manifest_modules. Same source, two module paths, two sets of items.
How it shows up
Building the engine at 1e21b9b emits, among 24 warnings:
warning: struct `OwnModuleScan` is never constructed
--> crates/fkst-framework/src/manifest_modules.rs:9:19
warning: function `scan_own_modules` is never used
--> crates/fkst-framework/src/manifest_modules.rs:15:15
warning: function `scan_lua_modules` is never used
--> crates/fkst-framework/src/manifest_modules.rs:92:4
warning: function `scan_lua_modules_inner` is never used
--> crates/fkst-framework/src/manifest_modules.rs:104:4
Twelve of the file's items are reported unused — effectively the whole file.
Meanwhile a sample of a running department process spends 100% of its stack in fkst_framework::manifest::manifest_modules::scan_lua_modules → scan_lua_modules_inner, at those same line numbers. The functions the build calls dead are the functions the appliance runs.
Why it is worth fixing rather than silencing
Reading those warnings honestly leads to deleting the file. Reading them the other way — assuming they are noise — is how a file stops being read at all. Either way the compiler is answering a question about a copy that does not exist at runtime, and it will keep doing so for every future change to this file.
The cost is not hypothetical: the live copy holds the module-index scan, which is where this appliance currently spends the majority of its CPU. That code is under a dead-code report saying nothing calls it.
What would close it
One declaration for one file. Whichever module path is the real one keeps it; the other declaration goes, and the warnings that survive then describe code that actually exists in the binary.
What happens
src/manifest_modules.rsis declared as a module twice, so the compiler builds two independent copies of it. One copy is reachable and runs; the other is dead. Every dead-code warning the file produces describes the copy nobody calls, which leaves the live copy with no dead-code signal at all.The two declarations
src/main.rs:44:src/manifest.rs:13-14:The
#[path]attribute points the second declaration at the same file, so it compiles ascrate::manifest::manifest_modulesalongsidecrate::manifest_modules. Same source, two module paths, two sets of items.How it shows up
Building the engine at
1e21b9bemits, among 24 warnings:Twelve of the file's items are reported unused — effectively the whole file.
Meanwhile a
sampleof a running department process spends 100% of its stack infkst_framework::manifest::manifest_modules::scan_lua_modules→scan_lua_modules_inner, at those same line numbers. The functions the build calls dead are the functions the appliance runs.Why it is worth fixing rather than silencing
Reading those warnings honestly leads to deleting the file. Reading them the other way — assuming they are noise — is how a file stops being read at all. Either way the compiler is answering a question about a copy that does not exist at runtime, and it will keep doing so for every future change to this file.
The cost is not hypothetical: the live copy holds the module-index scan, which is where this appliance currently spends the majority of its CPU. That code is under a dead-code report saying nothing calls it.
What would close it
One declaration for one file. Whichever module path is the real one keeps it; the other declaration goes, and the warnings that survive then describe code that actually exists in the binary.