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

To use dev-dependencies, you need to guard with cfg(all(kani, test)) #1258

Closed
tedinski opened this issue Jun 7, 2022 · 6 comments
Closed
Labels
[C] Feature / Enhancement A new feature request or enhancement to an existing feature. [E] User Experience An UX enhancement for an existing feature. Including deprecation of an existing one.

Comments

@tedinski
Copy link
Contributor

tedinski commented Jun 7, 2022

When cargo builds a project in test mode that has a dev-dependency, we see 3 basic calls to rustc (i.e. kani-compiler, in our case):

  1. Build the main project, but NOT IN TEST MODE (as a lib).
  2. Build the dev-dependency.
  3. Build the main project, now in test mode (as a bin).

We're adding --cfg=kani to all these calls, so if we gate on just cfg(kani) for the use of the dev-dependency, the first build will fail with an unknown import. (Possibly this is deliberate on cargo's part: ensuring cargo build will succeed before testing? Unfortunately, we inject our additional cfg(kani) so it's not actually the same as a cargo build...)

If you instead gate your proofs module with #[cfg(all(kani, test))], things will work properly. For example:

#[cfg(all(kani,test))]
mod proofs {
    use foo; // something from dev-dependencies
// ...
}

We should make this unnecessary, somehow. If we adopted #1214, then perhaps we could detect the lack of --test in kani-compiler and thus disable --cfg=kani. That would fix it...

@celinval
Copy link
Contributor

I would like to step back a bit and ask a more fundamental question. Do we want to pass --cfg=kani everywhere or just while compiling the target crate?

@tedinski tedinski added [C] Feature / Enhancement A new feature request or enhancement to an existing feature. [E] User Experience An UX enhancement for an existing feature. Including deprecation of an existing one. labels Nov 14, 2022
@tv42
Copy link

tv42 commented Jan 30, 2024

If I use #[cfg(all(kani,test))] in the library (not tests/), cargo kani no longer finds the proof (since test wasn't set):

No proof harnesses (functions with #[kani::proof]) were found to verify.

@celinval
Copy link
Contributor

Hi @tv42, you either have to pass --tests flag to Kani or you need to change your configuration to be #[cfg(any(kani,test))]

@celinval
Copy link
Contributor

I don't think there is much to do in this issue. The usage of cfg should reflect how the user wants to build their code.

@tv42
Copy link

tv42 commented Jan 31, 2024

#[cfg(any(kani, test))] isn't great because then tooling like rust-analyzer complains "use of undeclared crate or module kani".

I'll test cargo kani --tests after some current runs complete..

@celinval
Copy link
Contributor

celinval commented Feb 1, 2024

@tv42 can you please create an issue describing your case and the problems you are facing so we can assist you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C] Feature / Enhancement A new feature request or enhancement to an existing feature. [E] User Experience An UX enhancement for an existing feature. Including deprecation of an existing one.
Projects
None yet
Development

No branches or pull requests

3 participants