Comments (11)
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
from prusti-dev.
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.
from prusti-dev.
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?
from prusti-dev.
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?
from prusti-dev.
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 withpub
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.
from prusti-dev.
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.
from prusti-dev.
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.
from prusti-dev.
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.
from prusti-dev.
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.
from prusti-dev.
Thank you all for the suggestions. I will try to find some time to try them out.
from prusti-dev.
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).
from prusti-dev.
Related Issues (20)
- Support for old(..) expressions in loop invariants
- Wrong encoding of signed discriminants in pure code HOT 1
- Unsupported constant string in println HOT 1
- Wrong encoding of signed divisions HOT 2
- Inconsistency in the encoding of Rust addresses as Viper Ref types
- ghost seq not implemented HOT 1
- Error for missing model lifetime specifier recommends invalid syntax, has unclear fix HOT 3
- Enum discriminant completeness
- Enum: unsupported statement kind `Intrinsic(Assume(move _))`
- External specification declared on a trait implementation did not resolve to a concrete type
- `len()` implementation without overflow errors HOT 1
- Error: cannot generate fold-unfold Viper statements
- Assert(false) passing with Shared References HOT 1
- unsupported feature: determining the region of a dereferentiation is not supported
- cannot generate fold-unfold Viper statements
- Internal error: Location bb6[1] has not yet been encoded
- Prusti encounters unexpected internal error HOT 3
- Feature Request: Add Configuration Flag to Lower Verify Errors to Warnings HOT 1
- linux-aarch64: "cargo-prusti: cannot execute binary file: Exec format error"
- Prusti server stopped working HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from prusti-dev.