Fix SMT translation of integer literals#1107
Fix SMT translation of integer literals#1107Robertboy18 wants to merge 4 commits intostrata-org:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request fixes a type error in the SMT→Lean translation layer by ensuring integer literals are translated with Lean type Int (rather than Prop). This aligns literal typing with translateSort and fixes elaboration failures for integer-valued SMT terms such as ite branches.
Changes:
- Fix
translateTermso.prim (.int x)returns(Int, x)instead of(Prop, x). - Add a regression test exercising an integer-valued SMT
itethat compares against anIntliteral.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
Strata/DL/SMT/Translate.lean |
Corrects the Lean type returned for SMT integer literals during translation (mkInt instead of mkProp). |
StrataTest/DL/SMT/TranslateTests.lean |
Adds a regression test covering an integer-valued ite translated into Lean. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Addresses the two review comments on PR #1109: 1. `.app .str_length` silently built `Int.ofNat (String.length x)` even when `x` was not a `String`. Check the operand's translated type against `mkString` via a new `expectString` helper (shape mirrors `getBitVecWidth`), so malformed terms throw rather than producing an ill-typed `Expr` that only fails much later. 2. `.app .str_concat` delegated to `leftAssocOp`, which neither rejects fewer-than-two operands (despite its error message claiming it does) nor checks that operands have the expected type. So `.app .str_concat [s]` silently translated to `s`, and a mixed-type list produced an ill-typed `HAppend.hAppend`. Both diverged from `Denote.leftAssoc`. Inline the op instead: require two or more operands explicitly and `expectString` every operand, matching what `Denote.leftAssoc` does for `str_concat`. The underlying `leftAssocOp` bug (silent-singleton) affects every other caller (`.app .add`, `.app .sub`, `.app .mul`, `.app .div`, `.app .mod`, plus the bitvec analogues); it is pre-existing and will be fixed in a separate PR so that the change set can be reviewed on its own merits. Regression tests added in StrataTest/DL/SMT/TranslateTests.lean: - A >2-ary happy-path `str_concat` to cover the foldl tail. - `str_length` applied to a non-string operand. - Singleton `str_concat`. - `str_concat` with a non-string operand in first position. Each error-path test fails on the previous commit (producing the ill-typed `Expr` or the singleton pass-through) and passes here. Tests use `.prim (.bool _)` for the non-string operand so that the expected error message is stable regardless of how `.prim (.int _)` happens to be typed (see PR #1107). Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
|
I reran all the tests and it all worked! |
|
We will have to go through the shepherding process. (https://github.com/strata-org/Strata/blob/main/CONTRIBUTING.md#two-step-review-and-finding-a-shepherd). I will create a separate pull request which will include preserved commits under your email. |
Issue #, if available:
N/A. Found while working on leanprover/cslib#539.
Description of changes:
This fixes SMT translation of integer literals. Previously,
Strata.DL.SMT.Translate.translateTermtranslated.prim (.int x)as having Lean typeProp; this PR changes it toInt.This matters for integer-valued SMT
iteterms. In CSLib/Boole (Check: leanprover/cslib#539), an expression like:if i + 1 == n then 0 else i + 1was producing a VC elaboration error because the branch literal
0had typeIntbut was expected to have typeProp.This PR also adds a regression test covering an integer-valued SMT
ite.Checks run:
lake env lean StrataTest/DL/SMT/TranslateTests.leanlake env lean StrataTest/DL/SMT/DenoteTests.leanlake env lean StrataTest/DL/SMT/EncoderTests.leanlake build Strata.DL.SMT.Translate StrataTest.DL.SMT.TranslateTestsLet me know if you have any questions!
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.