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

get_impl_paths/recursion-checking does not handle Sync/Send inference #1335

Open
tjhance opened this issue Nov 5, 2024 · 2 comments
Open

Comments

@tjhance
Copy link
Collaborator

tjhance commented Nov 5, 2024

Consider this variation of the recently added test test_recursion_through_sync_impl_is_checked from 4ab656f:

trait Tr {
    proof fn tr_g() {
    }
}

struct Xinner<T, S> {
    rc: std::rc::Rc<u64>,
    t: T,
    s: S,
}

struct X<T, S> {
    inner: Xinner<T, S>,
}

#[verifier::external]
unsafe impl<T: Sync + Tr, S: Sync> Sync for Xinner<T, S> {
}


trait Sr {
    proof fn f() { }
}

struct Y<R> {
    r: R,
}

impl<W: Sync> Sr for Y<W> {
    proof fn f() { }
}


struct A1 { }

struct B1 { }

impl Tr for A1 {
    proof fn tr_g() {
        test();
    }
}

proof fn test() {
    let r = Y::<X<A1, B1>>::f();
}

The cycle has the dependency Xinner<T, S>: Sync --> X<T, S>: Sync which is not covered by get_impl_paths

@tjhance
Copy link
Collaborator Author

tjhance commented Nov 5, 2024

this might be okay appealing to the coinductiveness of Send/Sync? I'm not sure.

@Chris-Hawblitzel
Copy link
Collaborator

Not all cycles are unsound. For example, cycles through exec functions are sound and we don't need to report them as errors (unless we deliberately want to prohibit non-terminating exec functions). Mainly, we just need to guarantee termination of spec and proof functions.

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

No branches or pull requests

2 participants