module_loader.cpp: LoadModule() appears to be entirely dead code — confirm and delete
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
Research direction
Start with src/runtime/ext/module_loader.cpp and verify the repo-wide grep showing no callers of LoadModule(). Read the “Runtime-loaded modules” section of AGENTS.md and confirm the static-module path is the intended one. Done means maintainer-confirmed dead code is removed, including its 11 Log()/FatalError() call sites, with no remaining references.
Written by the indexing model from the issue text.
Description
Found while auditing log message quality in src/runtime/ext/module_loader.cpp (repo-wide log audit).
LoadModule() (the dynamic modules/*.dll loader, ~lines 51-138, 11 Log()/FatalError() call sites) has zero callers anywhere in the current codebase, verified by repo-wide grep. Per AGENTS.md's "Runtime-loaded modules" section (updated 2026-08-02), both real modules (platform-compat, token-auth) are now statically linked into BugSplat64.dll via RegisterStaticModule, and AGENTS.md's own list of infrastructure kept "for any future modules" names RegisterStaticModule/TickModules/NotifyModulesStateChange — conspicuously not LoadModule.
The log-audit commit for this file improved LoadModule()'s log/FatalError content on the assumption it might still be load-bearing (in case it's intentionally kept for a future dynamic-module path), but did not delete it.
Please confirm: is LoadModule() intentionally kept as scaffolding for a future dynamic-module capability, or is it dead code left over from before the 2026-08-02 static-linking change and safe to delete? If dead, recommend deleting LoadModule() and its associated 11 log call sites entirely rather than continuing to maintain them.
- Dominant language
- C
- Stars
- 2
- Forks
- 2
- Avg merge
- 8h 44m
- Merged PRs (30d)
- 72
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from EchoTools/nevr-runtime
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
EchoTools/nevr-runtime#171 · 1 comment ·
Maintainers usually reply within 1 day
-
backlog bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
EchoTools/nevr-runtime#152 · 1 comment ·
Maintainers usually reply within 1 day
-
backlog enhancement
Difficulty 1/5 Under an hour Newbie friendliness 85/100
EchoTools/nevr-runtime#147 · 1 comment ·
Maintainers usually reply within 1 day
-
telemetry_streamer: same set-once-header + auto-reconnect token-expiry bug as #39Possibly taken @thesprockee claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
EchoTools/nevr-runtime#114 · 1 comment ·
Maintainers usually reply within 1 day
-
crash-handler plugin: MH_ERROR_ALREADY_INITIALIZED treated as fatal, unlike every sibling pluginPossibly taken @thesprockee claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
EchoTools/nevr-runtime#26 · 1 comment ·
Maintainers usually reply within 1 day
All issues in EchoTools/nevr-runtime
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
libsdl-org/SDL#16464 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
backend
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
BasedHardware/omi#20940 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 Under an hour Newbie friendliness 70/100
Maintainers usually reply within 1 day