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

Provide Specs for the Standard Library #1249

Open
wants to merge 50 commits into
base: master
Choose a base branch
from

Conversation

juliand665
Copy link
Contributor

@juliand665 juliand665 commented Nov 24, 2022

As part of my thesis under @Aurel300, this pull request adds specifications to the most popular types & functions in the Rust Standard Library. I am using data gathered through qrates to inform decisions on what specs to prioritize, along with a sense of logical units, e.g. covering all members of the unconstrained Option<T> or Result<T, E> impls, rather than only specifying the subset of these methods that sees the most usage.

Outline of Planned & Completed Specifications

These specs are very much a work in progress and far from complete at the moment, though what is there should be sound.

core::option::Option

  • main impl

core::result::Result

  • main impl

core::clone::Clone

  • snapshot equality with opt-out mechanism

core::default::Default

  • purity (for usage in specs) with opt-out mechanism

specific default values

  • (), bool, char, numbers (the types specified here)
  • other commonly-used types

core::ops::Deref

  • purity (for usage in specs) with opt-out mechanism

This is currently blocked due to #1221.

core::ops::Index/core::ops::IndexMut

  • purity (for usage in specs) with opt-out mechanism

This is similarly blocked due to #1221.

core::ops::Try

  • impl for core::option::Option
  • impl for core::option::Result

core::mem::size_of

  • trait to allow users to specify what this method will return for their type
  • via the above, numbers, which are by far the most commonly-passed types

core::convert::From/Into

  • purity (for usage in specs) with opt-out mechanism
  • numeric conversions, which are again very common

Slices/Arrays

  • indexing with usize (built-in)
  • length (built-in)
  • "unsizing" arrays to slices

Indexing is currently blocked due to #1221.

alloc::vec::Vec

alloc::string::String

core::cmp::PartialEq/core::cmp::PartialOrd

These are currently blocked due to #1311.

Ranges

core::ops Binary Ops for References

These operations don't have blanket impls for when one or both sides are a reference, but their implementations are unified using macros, which probably makes sense for us to replicate.

Smart Pointers (e.g. alloc::rc::Rc)

This fundamentally relies on Deref and is thus also blocked by #1221.
Once that is resolved, specifying their Deref implementation as pure and expressing transfer into and out of a box via e.g. ensures(old(x) === snap(result.deref())) should go a long way towards specifying this type usefully.
Note that Box already has builtin support in Prusti, partly because Rust itself already treats it specially (e.g. that *box can move out of the box).

@Pointerbender
Copy link
Contributor

core::mem::size_of
trait to allow users to specify what this method will return for their type

That's exciting stuff! Would this also be possible for core::mem::align_of, by any chance? :)

@juliand665
Copy link
Contributor Author

Would this also be possible for core::mem::align_of, by any chance? :)

Sure! For the values so far, size and alignment seem to be the same, so that should be really simple. Interestingly, it seems that align_of is not commonly called with these types. I'll specify it anyway since it's so simple though.

includes inheritance of postconditions and auto trait "transitivity"
have to desugar this manually since prusti syntax breaks rust's macro parsing
@juliand665 juliand665 marked this pull request as ready for review February 13, 2023 02:51
@juliand665
Copy link
Contributor Author

Oh yeah, to establish a link: this resolves #941!

@Aurel300 Aurel300 enabled auto-merge (rebase) May 5, 2023 09:48
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

Successfully merging this pull request may close these issues.

5 participants