Summary
The static analyzer raises warning[ANALYZE-UNUSED]: Unused variable 'X'
even when the variable is referenced by add N to X. The counter is in
fact both read and written by that statement, but the analyzer seems to
not model add ... to ... as a use.
Same (or related) issue applies to the not_found variable in the repro —
it's referenced inside a respond ... with not_found ... statement and still
flagged as unused.
Environment
- WFL 26.4.1 (git 8d8ab44, 2026-04-24)
Minimal repro
// save as unused_fp.wfl
store req_count as 0
store greeting as "hello"
listen on port 8080 as s
main loop:
wait for request comes in on s as r
add 1 to req_count // this should count as a use of req_count
display "req #" with req_count // and so should this
respond to r with greeting // greeting is used here too
end loop
Then:
wfl --analyze unused_fp.wfl
Output (trimmed):
warning[ANALYZE-UNUSED]: Unused variable 'req_count'
= Consider removing this variable if it's not needed
Expected
No warnings. req_count is:
- written once by
store req_count as 0
- read + written by
add 1 to req_count
- read by
display ... with req_count
Any of those three should mark it as used.
Actual
The analyzer emits the ANALYZE-UNUSED warning. Functionally the program
runs correctly (the counter does increment and display), so this is a
reporting bug, not a correctness bug — but the noise is distracting, and
users following the warnings' advice (Consider removing this variable if it's not needed) would delete counters that are actually in use.
Related observations
A similar pattern showed up during our deployment: a store not_found as "<html>..." variable was referenced inside a respond to req with not_found and status 404 statement and still got flagged. So the analyzer may be
missing a whole family of uses — not just add ... to ... but also uses
inside respond ... with <var> .... Might be worth a single sweep through
the analyzer's use-tracking to verify every statement kind increments the
per-variable use count.
Fix sketch (unverified)
Wherever the analyzer walks the AST counting variable uses, audit the visitor
for:
add/subtract/multiply/divide ... to/from/by ... (compound-assignment forms)respond to ... with <expr> ... (HTTP response body argument)display ... with <expr> ... (string-interpolation-style)
If any of those are falling through without recording a use, that's the
culprit.
Related
Summary
The static analyzer raises
warning[ANALYZE-UNUSED]: Unused variable 'X'even when the variable is referenced by
add N to X. The counter is infact both read and written by that statement, but the analyzer seems to
not model
add ... to ...as a use.Same (or related) issue applies to the
not_foundvariable in the repro —it's referenced inside a
respond ... with not_found ...statement and stillflagged as unused.
Environment
Minimal repro
Then:
Output (trimmed):
Expected
No warnings.
req_countis:store req_count as 0add 1 to req_countdisplay ... with req_countAny of those three should mark it as used.
Actual
The analyzer emits the
ANALYZE-UNUSEDwarning. Functionally the programruns correctly (the counter does increment and display), so this is a
reporting bug, not a correctness bug — but the noise is distracting, and
users following the warnings' advice (
Consider removing this variable if it's not needed) would delete counters that are actually in use.Related observations
A similar pattern showed up during our deployment: a
store not_found as "<html>..."variable was referenced inside arespond to req with not_found and status 404statement and still got flagged. So the analyzer may bemissing a whole family of uses — not just
add ... to ...but also usesinside
respond ... with <var> .... Might be worth a single sweep throughthe analyzer's use-tracking to verify every statement kind increments the
per-variable use count.
Fix sketch (unverified)
Wherever the analyzer walks the AST counting variable uses, audit the visitor
for:
add/subtract/multiply/divide ... to/from/by ...(compound-assignment forms)respond to ... with <expr> ...(HTTP response body argument)display ... with <expr> ...(string-interpolation-style)If any of those are falling through without recording a use, that's the
culprit.
Related
is just to ignore the warnings (or to drop the counter, which for our
splash server was actually a fine simplification).