Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Closure" error in pearlite #1215

Open
Armael opened this issue Nov 1, 2024 · 6 comments
Open

"Closure" error in pearlite #1215

Armael opened this issue Nov 1, 2024 · 6 comments

Comments

@Armael
Copy link
Contributor

Armael commented Nov 1, 2024

It look like the closure syntax is allowed in pearlite!{} blocks to define Mappings, but when trying to use it in a proof_assert!{} I get an error from creusot.

#[logic]
#[ensures(true)]
fn foo() {
    proof_assert!{
        let f: Mapping<Int,Int> = { |k:Int| 42 };
        true
    };
}

raises the error Closure(path/to/file.rs)

@Armael
Copy link
Contributor Author

Armael commented Nov 1, 2024

Actually, proof_assert! looks like a red herring here. I'm getting the same issue with the following program:

#[logic]
#[ensures(true)]
fn foo() -> Seq<Int> { pearlite!{
    Seq::create(42, { |k:Int| 42 })
}}

@Armael Armael changed the title Closure syntax allowed in pearlite!{} but not in proof_assert!{} "Closure" error in pearlite Nov 1, 2024
@Armael
Copy link
Contributor Author

Armael commented Nov 1, 2024

Ah, the #[ensures(true)] seems to be required for the error to appear.

@xldenis
Copy link
Collaborator

xldenis commented Nov 1, 2024

Yes, the logic vcgenerator doesn't support closures.

@Armael
Copy link
Contributor Author

Armael commented Nov 1, 2024

I had assumed that adding contracts to a logical function simply generate a proof obligation of the form forall x y z. pre(x,y,z) ==> post(x,y,z,func(x,y,z)), which doesn't seem to require a specific VCgen as long as the definition of func is transparent.
Is this not how it works? (and if so, why?)

@xldenis
Copy link
Collaborator

xldenis commented Nov 1, 2024

the VC it generates is a bit more complex than this, but that is the principle, the issue though is what happens if your closure contains a recursive call? what if it contains an expression with preconditions etc..

the current vc is extremely conservative.

@jhjourdan
Copy link
Collaborator

YEah, but we should really do something (even if stupid) with every language construct, including closures.

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

No branches or pull requests

3 participants