Update to latest about prusti-dev

[Ereski]

Maybe I am missing something obvious, but I do not see how can I use the newest compiler interface to obtain an AST which I can mutate and then feed back into the compiler so that it gets typechecked.

For this case, where you are just extracting an expression from an attribute into a function (as far as I understand), it looks like you can just use libsyntax/syn + quote and then modify the parse_sess struct in the session field of that Compiler struct to point to the expanded source file.

Edit: I've started work on rebasing to nightly-2019-10-02 (the latest nightly w/ rustfmt and clippy): https://github.com/Ereski/prusti-dev/tree/update

[vakaras]

The main blocker regarding the update to the newest version of rustc is that rustc does not provide API anymore that allows changing AST. Therefore, we need to find a new way of doing specification parsing and type-checking. One idea we have is to use procedural macros, but we are not convinced yet that they will work in all cases we need.

[davidbarsky]

I'm interested in hearing what sort of use-cases are missing from procedural macros—I believe that as of Rust 1.40, procedural macros can be placed in most positions, either directly, or through https://github.com/dtolnay/proc-macro-hack. However, "type-checking" is somewhat broad—can you elaborate on that?

[Ereski]

The main blocker regarding the update to the newest version of rustc is that rustc does not provide API anymore that allows changing AST.

I'm not familiar with how prusti works under the hood, but from a cursory check it looks like the AST you get from libsyntax is pretty much wide open with pub access everywhere. Or are you referring to MIR or something else?

[vakaras]

However, "type-checking" is somewhat broad—can you elaborate on that?

Let's say you have the following trait:

trait T {
  #[requires="-10 < x && x < 10"]
  fn foo(x: i32);
}

We would like to know what are the (fully resolved) types of all subexpressions in the precondition. What we do know is to create a new function that has the precondition as a normal code and let the compiler to type-check it for us:

fn T__foo(x: i32) {
  use prusti_contracts::__assert;
  __assert(4412453, -10 < x && x < 10); // We use UUIDs to map back assertions to their original positions.
}
trait T {
  #[requires_id=4412453]
  fn foo(x: i32);
}

The problem with procedural macros is that, as far as I know, with them it is impossible to create function T__foo because the macro can only rewrite foo, which is inside trait T. If you know how to work-around this, I would be very happy to hear.

it looks like the AST you get from libsyntax is pretty much wide open with pub access everywhere.

Maybe I am missing something obvious, but I do not see how can I use the newest compiler interface to obtain an AST which I can mutate and then feed back into the compiler so that it gets typechecked.

[davidbarsky]

Thanks for explaining! I'm a bit short on time—for which I apologize—but you're right, as procedural macros exist right now, the generated T__foo(x: i32) can't be generated outside to scope of fn foo(x: i32). While this isn't a 1:1 correspondence, the async-trait crate does some a similar sort of trait rewriting in a hygienic manner. I think something like this should be expressible:

#[verified]
trait T {
  #[requires_id=4412453]
  fn foo(x: i32);
}

...where the #[verified] annotation allows codegen to exist within the scope of the trait T, but perhaps an expert on procedural macros can correct me.

[vakaras]

Yes, I think such #[verified] annotation would be an option, but also quite annoying for the user to put it on basically all traits. Therefore, if possible, I would like to avoid it.

[davidbarsky]

@vakaras

Maybe I am missing something obvious, but I do not see how can I use the newest compiler interface to obtain an AST which I can mutate and then feed back into the compiler so that it gets typechecked.

If I'm understanding you correctly, syn + quote should do the trick.

Yes, I think such #[verified] annotation would be an option, but also quite annoying for the user to put it on basically all traits. Therefore, if possible, I would like to avoid it.

That's fair. Having read the original publication, I walked away from the impression that most of the verified functions were free functions, hence this suggestion 🙂. Looking at one of the tests, I'm guessing that Effective::set is verified by the same constraint as Percentage::set, which is #[requires="arg <= 100"]? If so, I don't believe there are any plans to support this in rust using the procedural macro interface due to hygiene issues. For what its worth, I've been using #[async-trait] macro regularly, and it does not feel burdensome—I've only had to write that a few times.

[fpoli]

Regarding the #[verified], if I understand this comment correctly the test framework managed to have a whole-crate procedural macro applied as a rustc argument. That would be a nice solution to hide the proc-macro from a Prusti user.

[vakaras]

Thank you all for the suggestions. I will try to find some time to try them out.

[Aurel300]

We now regularly update to the latest nightly. The specification parsing was implemented as suggested above, though it might change again (#401). Some dependencies need to be updated, although we are pending on a rustc issue (#415).