Let dolmen fix that for you

[Gbury]

Long-term thread to list the various little errors that dolmen could accept during typing, in order to eventually allow to "fix" problems once problem export in dolmen has been implemented. This would be done either when using --strict=false or even another option (--strict=fix ?).

[hansjoergschurr]

Here is a list of things that come to mind:

• n-ary operators, such as and, applied to only one argument
• the bitvector operator concat applied to more than two arguments
• replacement of non-standard *_i bitvector operations with the normal variant (see smtlib2 file generated by z3 API cannot be parsed by other SMT solvers Z3Prover/z3#1133)
• Safe integer promotion: applying built-in operators to an integer and a real at the same time is forbidden. For example, (= 5 5.0) is illegal. In those cases, however, the integer can safely be promoted to a real by either using to_real, or adding a .0 suffix.

[Gbury]

Another example: some problems may contain solver-reserved identifiers, particularly when they are created from the output of some solvers (see e.g. https://clc-gitlab.cs.uiowa.edu:2443/SMT-LIB-benchmarks/QF_BV/-/blob/master/20190429-UltimateAutomizerSvcomp2019/byte_add_1_true-unreach-call_true-no-overflow_true-termination.i_6.smt2 ), it would be useful to be able to parse (and type) them to then print them with correct names.

[hansjoergschurr]

Does dolmen produce an error for those? I have some preliminary work on doing large scale back experiments on SMT-LIB and it would be a good opportunity to mark such.

[Gbury]

It's fairly recent addition indeed: PR #193 made it so that it is an error to use symbols that start with an @ or a .. Indeed, the smtlib specification states that such identifiers are reserved for solver use, and therefore should not appear in input scripts.

It might be a problem for problems generated by solver-like programs indeed, and I should probably try and run a check on the whole smtlib to see whether this is a frequent occurrence. That being said, I think that such generated problems should respect the spec, since solvers might assume that all of the identifiers starting with an @ or a . are free for them to use, and thus problems using these identifiers might result in name collisions.

[Gbury]

In the meantime, and depending on how many problems in the smtlib use such solver-reserved identifiers, I'll consider changing the error into a warning, which would be fatal by default, but that could be turned off/not fatal if wanted/required by users.