Skip to content

[Draft] Add assert timeout configuration option for Silicon backend#1013

Draft
jcp19 wants to merge 3 commits into
masterfrom
claude/add-assert-timeout-cli-DcDg7
Draft

[Draft] Add assert timeout configuration option for Silicon backend#1013
jcp19 wants to merge 3 commits into
masterfrom
claude/add-assert-timeout-cli-DcDg7

Conversation

@jcp19
Copy link
Copy Markdown
Contributor

@jcp19 jcp19 commented Apr 10, 2026

Summary

This PR adds support for configuring a timeout (in milliseconds) for assert operations performed by the Silicon backend. The timeout can be specified via the --assertTimeout command-line flag and is only applicable when using Silicon or ViperServer with Silicon as the backend.

Key Changes

  • Added --assertTimeout command-line option via Scallop configuration
  • Implemented merge logic for assertTimeout that takes the minimum value when both configs specify a timeout (most restrictive)
  • Added validation to ensure:
    • The flag is only used with Silicon-based backends
    • The timeout value is a positive integer (milliseconds)

EDIT: the test for this feature is currently failing. This failure seems to come from silicon itself (it is unclear if the assert timeout is being enforced). Please ignore the PR for now.

claude added 2 commits April 10, 2026 13:45
Exposes Silicon's --assertTimeout option through Gobra's CLI, allowing
users to set a per-assertion timeout in milliseconds. The option is
Silicon-specific and guarded by validation to reject use with Carbon.

https://claude.ai/code/session_01DNDg4ADj7NW35SQMt26uD2
The test defines an abstract ghost pure function `magic` (uninterpreted)
and a method that assumes a quantifier whose trigger creates a matching
loop. With a 1-second assert timeout set via inline config, Silicon
correctly reports the assertion as failed instead of looping forever.

https://claude.ai/code/session_01DNDg4ADj7NW35SQMt26uD2
@jcp19
Copy link
Copy Markdown
Contributor Author

jcp19 commented Apr 10, 2026

Human here:

I edited the PR description, I reviewed the code, and vouch for both.

I find this option particularly useful in combination with a proposed change I discussed yesterday with Nick (@rayman2000) and Marco (@marcoeilers): to introduce a new type of error reason for proof obligations that time out. This is useful not only for humans debugging performance issues (e.g., understanding which precondition is taking forever to verify on a method-call) and to LLMs, as they would get more info on what the cause of verification error is on those cases. Ofc, we need to open a new PR to support that kind of error-reason if and when it is introduced in Viper.

EDIT: if that error reason is eventually introduced in Viper, I think it is worth having a permissive (but finite) default value for the assert timeout in Gobra (10-15s). This would make Gobra more beginner friendly, as the new users would have a clear indication that something is not ideal about their queries

Comment thread src/test/resources/regressions/features/assert_timeout/dangerous_triggers.gobra Outdated
@jcp19 jcp19 requested a review from ArquintL April 10, 2026 14:18
@jcp19 jcp19 marked this pull request as draft April 10, 2026 15:59
@jcp19 jcp19 changed the title Add assert timeout configuration option for Silicon backend [Draft] Add assert timeout configuration option for Silicon backend Apr 10, 2026
@jcp19
Copy link
Copy Markdown
Contributor Author

jcp19 commented Apr 11, 2026

Funnily enough, the added test does not terminate because the long verification times occur due to a push, not an assert. We could in principle configure the pushTimeout as well (silicon already supports this), but the SMT solver seems to ignore this parameter

@ArquintL
Copy link
Copy Markdown
Member

Funnily enough, the added test does not terminate because the long verification times occur due to a push, not an assert. We could in principle configure the pushTimeout as well (silicon already supports this), but the SMT solver seems to ignore this parameter

What happens on push? Is the SMT solver automatically figuring out whether there are any inconsistencies?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants