Sleeping/Impure overrides incorrectly prevent checking rest of call graph #267
Description
Vaguely similar to #247 and likely linked, but specific enough that it really looks like an implementation bug
Consider the following file:
/datum/proc/do_things()
set SpacemanDMM_should_not_sleep = 1
/datum/proc/thing()
do_complicated_thing()
/datum/sub/do_things()
thing()
/proc/do_complicated_thing()
usr.client.SoundQuery()
This works as expected:
onefile.dm, line 8, column 21:
error: /datum/sub/proc/do_things sets SpacemanDMM_should_not_sleep but calls blocking proc /proc/do_complicated_thing
- 3:2: SpacemanDMM_should_not_sleep set here
- 9:2: /datum/proc/thing() called here
- 6:2: /proc/do_complicated_thing() called here
- 12:12: client.SoundQuery() called here
Now strap at the end funny hijack proc, on a different subtype:
/datum/zzz/thing()
sleep(10)
Result:
Procs analyzed: 5. Errored: 0. Builtins: 335.
============================================================
Analyzing proc override validity...
============================================================
Analyzing proc call tree...
============================================================
Found 0 diagnostics
Funny huh? In our real world example, this was even more awkward from the fact this still generated a warning, that was also ignored by the same override setting waitfor=0