Skip to content

Add non-fatal failure check to rmc prelude #695

Closed as not planned
Closed as not planned

Description

@celinval

Requested feature: Provide a mechanism for users to add property check to their code that do not abort the program when a failure occurs.
Use case: This can be extremely helpful for adding more information to potential fatal failures without affecting the code path. This can also help while writing tests for RMC.
Link to relevant documentation (Rust reference, Nomicon, RFC):
Is this a breaking change? None

Test case:

/// Dummy verification harness that ensures that method shuffle generates a new array that has all the
/// elements from the source array.
#[rmc::proof]
fn check_shuffle() {
    let a1: [u8; 5] = rmc::nondet();
    let a2 = shuffle(&a1);
    rmc::check(a2.size() == a1.size());
    for x in &a1 {
        rmc::check(a2.contains(x));
    }
}

In this harness, it might be helpful to understand if 1 or more items are missing from the array. With rmc::check() we can easily verify all the elements and find as many failures as possible. If we replace rmc::check by assert the analysis would stop in the first failure.

Activity

  1. self-assigned this
    on Dec 14, 2021
  2. celinval commented on Dec 14, 2021

    @celinval
    ContributorAuthor

    Note to self: Revert the hack made to the existing testcases here: #687

  3. adpaco commented on Nov 23, 2022

    @adpaco
    Contributor

    Found this issue while looking for "shuffle"... Is this something we still want?

  4. celinval commented on Nov 24, 2022

    @celinval
    ContributorAuthor

    I'm OK closing this.

  5. tedinski commented on Nov 28, 2022

    @tedinski
    Contributor

    I still want kani::check, re-opening unless I get overruled :)

    I think it'd at least be good for ourselves writing tests, and possibly as extra documentation making it clear that assert aborts execution.

  6. carolynzech commented on Jan 9, 2025

    @carolynzech
    Contributor

    @celinval should we close this as "won't do? given #3561?

  7. celinval commented on Jan 10, 2025

    @celinval
    ContributorAuthor

    Closing this one since we haven't found any use case for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

[C] Feature / EnhancementA new feature request or enhancement to an existing feature.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions