Comments (4)
(I can't test this atm, but) does it make a difference if you remove these two postconditions from the extern spec?
#[ensures(!result <==> self.is_none())]
#[ensures(!result <==> self.is_some())]
from prusti-dev.
It does not seem to make any difference... I've commented both/either one of them out, and they crash.
I've also tried changing to
#[ensures(!result == self.is_none())]
,#[ensures(result != self.is_none())]
, as well as annotating is_none(..)
as trusted, but none of these seem to work either
If I comment out both post-conditions for None
#[pure]
pub fn is_none(&self) -> bool;
then, Prusti does not crash, but then it wouldn't be very helpful since we can't verify
#[pure]
#[ensures(u <= 10 ==> result.is_none())] // this fails
pub fn filter(&self, u: u32) -> Option<u32> {
if u > 10 {
return Some(u)
}
return None
}
from prusti-dev.
This bug happens for the same reason as #1391. The problem is that for enums which are only used in specifications (pre- and postconditions, assertions) of a function but not in its body, some functions and axioms are not generated in the viper domain of the snapshot type. In particular, some constructors and the discriminant axioms are missing. In this case, the injectivity axiom is still present and refers to a missing constructor:
domain Snap$m_std$$option$$Option$_beg_$u32$_end_ {
function discriminant$__$TY$__Snap$m_std$$option$$Option$_beg_$u32$_end_$Snap$m_std$$option$$Option$_beg_$u32$_end_$$int$(self: Snap$m_std$$option$$Option$_beg_$u32$_end_): Int
function cons$0$__$TY$__Snap$m_std$$option$$Option$_beg_$u32$_end_$Snap$m_std$$option$$Option$_beg_$u32$_end_(): Snap$m_std$$option$$Option$_beg_$u32$_end_
axiom Snap$m_std$$option$$Option$_beg_$u32$_end_$1$injectivity {
(forall _l_0: Int, _r_0: Int ::
{ cons$1$__$TY$__Snap$m_std$$option$$Option$_beg_$u32$_end_$$int$$Snap$m_std$$option$$Option$_beg_$u32$_end_(_l_0),
cons$1$__$TY$__Snap$m_std$$option$$Option$_beg_$u32$_end_$$int$$Snap$m_std$$option$$Option$_beg_$u32$_end_(_r_0) }
cons$1$__$TY$__Snap$m_std$$option$$Option$_beg_$u32$_end_$$int$$Snap$m_std$$option$$Option$_beg_$u32$_end_(_l_0) ==
cons$1$__$TY$__Snap$m_std$$option$$Option$_beg_$u32$_end_$$int$$Snap$m_std$$option$$Option$_beg_$u32$_end_(_r_0) ==>
_l_0 == _r_0)
}
}
We can work around this bug by explicitly mentioning the type in the function body, which causes everything in the snapshot domain to be generated:
#[pure]
fn test(u: u32) -> Option<u32> {
return None
}
#[requires(test(10).is_none())]
fn main() {
let _: Option<u32> = None;
}
from prusti-dev.
Hi,
There seems to be a similar bug with Option::Some(..)
as well.
For instance, if we have a function that always returns Some(usize)
,
#[pure]
pub fn some_obj(&self) -> Option<usize> {
Some(10)
}
#[pure] // does not affect results
#[ensures(result <==> self.some_obj().is_some())]
pub fn is_true(&self) -> bool {
let _: Option<usize> = None;
true
}
Prusti crashes if the post-condition for is_true(..)
is imposed, even if we mention the type explicitly and remove the pure
annotation. On the other hand when a similar tactic is used for some_obj(..)
, i.e.,
#[pure]
pub fn some_obj(&self) -> Option<usize> {
let obj: Option<usize> = Some(10);
obj
}
the explicit mentioning of the type makes Prusti crash, only if the fuction is marked as pure.
from prusti-dev.
Related Issues (20)
- Help message for x.py
- Internal error when assigning to an argument
- Internal error when assigning a closure call to a reference
- rustc removed plugins HOT 2
- Update rust nightly to support codegen-backend HOT 1
- Failing procedural macro of a contract
- Unexpected order of verification errors
- Verifying 3rd party dependency crate results in compiler panic HOT 14
- Executable mode bits in release files not set HOT 4
- 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
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.