Skip to content

Add a parser for full Smtlib scripts - #717

Open
daniel-raffler wants to merge 106 commits into
masterfrom
antlrParser
Open

daniel-raffler wants to merge 106 commits into
masterfrom
antlrParser

Conversation

@daniel-raffler

@daniel-raffler daniel-raffler commented Sep 28, 2026 •

Copy link
Copy Markdown
Contributor

Hello,

this PR adds a antlr parser and evaluator for Smtlib scripts to JavaSMT. To start the parser a new method parseAndRun was added to FormulaManger:

List<SolverResponse> parseAndRun(String smtlib)

The method will parse and evaluate a Smtlib script. Responses from the solver to commands such as (check-sat) or (get-model) are logged and returned to the caller, so that they can be printed later

There is also a asynchronous version of the method that returns solver responses right away, which can be useful for long running scripts:

void parseAndRun(Consumer<SolverResponse> responseListener, String smtlib)

While this PR is very large, a lot of the code is either boilerplate or autogenerated by Antlr. The interesting parts can be found here:

  • Smtlib.g4 Antlr grammar for Smtlib
  • Predefined Theory symbol definitions
  • SmtlibEvaluator Smtlib evaluator to run the script after parsing

Note that the PR also includes a new parsing delegate to track user-defined symbols for the parser. It has some overlap with the various variable caches we already have for the solvers, and we may be able to get rid of it if we decide to make the Antlr parser the default option

Known issues:

  • Z3 takes a very long time in SolverContext.close() after parsing large files. This may be related to its garbage collector as all parsed terms now need to be tracked individually (Mostly) fixed by enabling phantom references

…or as some solvers don't support all theories
Affected left associate operations like "substraction" where the arguments of the operation were in the wrong order
…luator"

On second thought, it's probably best not to import the symbols and insist that every symbol that is used in the script must also be declared there. This avoids ambiguity about the type when capturing variables from the solver context
# Conflicts:
#	lib/ivy.xml
#	src/org/sosy_lab/java_smt/SolverContextFactory.java
#	src/org/sosy_lab/java_smt/test/FormulaManagerTest.java
#	src/org/sosy_lab/java_smt/test/SolverBasedTest0.java
…add a new method `FormulaManager.parseScript` to run entire Smtlib scripts

This branch has not been deployed

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

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Improve SMTLIB2 Parsing and Tokenizing Yices2 Parser Problems

1 participant