The input-signature inference recovers per-context tensor shapes by traversing the call graph at a targeted k-CFA depth. When that depth is too short, the call strings do not reach the relevant context (for example, a parameter bound to a model-forward output), and the inference falls back to ⊤ (UNKNOWN). There is currently no signal that an insufficient depth, rather than a genuinely unknown value, produced the ⊤, so a user cannot tell that increasing the depth would help.
Java 8 Stream Refactoring has the analogous mechanism: NoApplicationCodeExistsInCallStringsException is raised when the call strings within the configured length (nToUseForStreams) never reach application code, signaling that the length must be increased. It began as an exception (crash, increase the length, repeat to a per-subject fixed point) and was later softened to a warning (ponder-lab/Optimize-Java-8-Streams-Refactoring#176).
Add an analogous signal here: detect when the call strings within the targeted CFA depth fail to reach the relevant application context, so a ⊤ that stems from an insufficient depth can be reported (warning or exception) and the depth tuned to a per-subject fixed point. The one subtlety is distinguishing a too-short-depth ⊤ from a genuinely-unknown ⊤.
Client context: the Hybridize Functions refactoring exposes this depth as a per-project targetedCfaDepth (via eval.properties), with no empirical way to know when it is too short.
The input-signature inference recovers per-context tensor shapes by traversing the call graph at a targeted k-CFA depth. When that depth is too short, the call strings do not reach the relevant context (for example, a parameter bound to a model-forward output), and the inference falls back to
⊤(UNKNOWN). There is currently no signal that an insufficient depth, rather than a genuinely unknown value, produced the⊤, so a user cannot tell that increasing the depth would help.Java 8 Stream Refactoring has the analogous mechanism:
NoApplicationCodeExistsInCallStringsExceptionis raised when the call strings within the configured length (nToUseForStreams) never reach application code, signaling that the length must be increased. It began as an exception (crash, increase the length, repeat to a per-subject fixed point) and was later softened to a warning (ponder-lab/Optimize-Java-8-Streams-Refactoring#176).Add an analogous signal here: detect when the call strings within the targeted CFA depth fail to reach the relevant application context, so a
⊤that stems from an insufficient depth can be reported (warning or exception) and the depth tuned to a per-subject fixed point. The one subtlety is distinguishing a too-short-depth⊤from a genuinely-unknown⊤.Client context: the Hybridize Functions refactoring exposes this depth as a per-project
targetedCfaDepth(viaeval.properties), with no empirical way to know when it is too short.