Pass mkDischarge through PyAnalyzeConfig to verifyProgram#1200
Conversation
Add mkDischarge field to PyAnalyzeConfig with default Core.mkDischargeFn, and forward it to Core.verifyProgram in the verification phase. This allows callers of runPyAnalyzePipeline to supply a custom solver discharge function.
…e-parameterization-lost-in-squ
|
Thanks for the quick fix! This covers the However, the
so that downstream executables can override the discharge function for both commands? |
|
🤖 Addressed — |
|
One more request: could -def pyAnalyzeLaurelCommand : Command where
+def pyAnalyzeLaurelCommand (mkDischarge : Core.MkDischargeFn := Core.mkDischargeFn) : Command whereand inside the callback where - let config : PyAnalyzeConfig := { ... }
+ let config : PyAnalyzeConfig := { ..., mkDischarge }With both commands parameterized, a downstream exe is just: commandMap
|>.insert "verify" (verifyCommand (mkDischarge := myFn))
|>.insert "pyAnalyzeLaurel" (pyAnalyzeLaurelCommand (mkDischarge := myFn)) |
|
🤖 Done — |
MikaelMayer
left a comment
There was a problem hiding this comment.
🤖🔍 Clean, minimal PR. The mkDischarge parameter is threaded correctly through PyAnalyzeConfig, pyAnalyzeLaurelCommand, and verifyCommand, all with appropriate defaults preserving backward compatibility. The existing call sites at lines 1426/1431 continue to work without arguments. No issues found.
The
mkDischargeparameter was accepted byCore.verifyProgrambut not exposed throughPyAnalyzeConfigor the CLIverifycommand, so callers could not supply a custom solver discharge function.This PR:
mkDischargetoPyAnalyzeConfig(defaulting toCore.mkDischargeFn) and forwards it to the verification call.mkDischargeas a parameter toverifyCommandand passes it through to theverifycall.mkDischargeas a parameter topyAnalyzeLaurelCommand(same pattern), so downstream executables can override the discharge function without redefining the command.Tested: existing tests pass, build succeeds.
Fixes #1199