ek9_find_inline_candidates
Answers candidates[] (file, line, name, tier worth-inlining | safe, useCount) ranked slop-first, with counts{} - every local '<-' declaration in scope examined.
When to use it
'Which local temps add nothing over their initialiser' is one call, no arguments (fileFilter or module to scope it) - an empty list is a convergence signal.
When not to use it
- Applying the inline - use
ek9_inline_variableto perform each transform. - Finding callables to DELETE (dead code) - use
ek9_find_unused_code(the delete mirror). - A local with NO references - this tool skips those; use
ek9_safe_deleteinstead.
Details
Classified with VariableInliner.classify(), the SAME rules as the ek9_inline_variable transform, so every finding is actionable. Two tiers: 'worth-inlining' = a trivial initialiser (literal / bare name / dotted access, no call or operator) used EXACTLY once - a redundant temp; 'safe' = mechanically inlinable but the name may still document intent (non-trivial single use, a pure value reused, or trivial-but-multi-use, where inlining can trip magic-literal E11065). Never surfaced: control-flow guards, reassigned locals, multi-line initialisers, locals with no references, and call-bearing initialisers used more than once; needs only a PARSED workspace (run ek9_compile first), no call graph.
Arguments
| Argument | Type | Required | What it is |
|---|---|---|---|
fileFilter | string | Optional case-insensitive substring on the source path to scope the scan (per-file or per-directory). Omit to scan all source. | |
module | string | Optional exact module name to scope the scan (per-module). Omit to scan all modules. |
It also takes the arguments every tool takes.
See also
- Show me in the IDE: Inline Candidates