Let dolmen fix that for you about dolmen HOT 5 OPEN

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 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.

from dolmen.

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.

from dolmen.

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.

from dolmen.

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.

from dolmen.

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.

from dolmen.