Cyclic dev dependency get type mismatch error

help
1

I'm trying to extract a test utility in project, but doing this comes to a type mismatch error.
I have created a minimal example to show the error.
Github repo:
https://github.com/kaichaosun/test-workspace-dependency

Any help or directions are appreciate.

2

The github repo contains the code, I will also brief list it here, there are two crates, one is test-utils, another is client,
This is the client code with a dev-dependency on test-utils:

#[derive(Eq, PartialEq, Debug)]
pub struct Name {
	pub first_name: String,
	pub last_name: String,
}

pub fn full_name(first: String, last: String) -> Name {
	Name {
		first_name: first,
		last_name: last,
	}
}

mod test {
	use super::*;

	#[test]
	fn full_name_works() {
		assert_eq!(
			full_name(String::from("hello"), String::from("world")), 
			test_utils::helper()
		)
	}
}

This is test-utils code with a dependency on client:

use client::Name;

pub fn helper() -> Name {
	Name {
		first_name: String::from("hello"),
		last_name: String::from("world"),
	}
}

Running cargo test in the workspace shows error:

error[E0308]: mismatched types
  --> client/src/lib.rs:19:3
   |
19 |           assert_eq!(
   |  _________^
20 | |             full_name(String::from("hello"), String::from("world")),
21 | |             test_utils::helper()
22 | |         )
   | |_________^ expected struct `Name`, found struct `client::Name`
3

I do not know what is going on. Does the following match your intuition ?

  1. you execute 'cargo test' in crate-client

  2. because we are testing, this is built in 'dev mode', compiling crate-client in dev-mode

  3. so https://github.com/kaichaosun/test-workspace-dependency/blob/master/client/src/lib.rs#L20 is actually dev-mode::crate-client::Name

  4. brecaause of https://github.com/kaichaosun/test-workspace-dependency/blob/master/client/Cargo.toml#L14-L15 we now build crate-test-utils in "regular mode"

  5. in building crate-test-utils, because of https://github.com/kaichaosun/test-workspace-dependency/blob/master/test-utils/Cargo.toml#L14-L15 , we build crate-client in "normal mode"

  6. https://github.com/kaichaosun/test-workspace-dependency/blob/master/client/src/lib.rs#L21 then ends up being normal-mode::crate-client::Name

  7. so the assert_eq ends up comparing dev-mode::crate-client::Name vs normal-mode::crate-client::Name ?

Is there a way we can verify / refute this theory ?

4

(I do not understand the compiler internals; this is just me guessing.)

Intuitively, it seems that to resolve this cyclical dependency, we need something like:

normal/crate-client depends on
normal/test-utils depends on [normal/crate-client]
dev/crate-client depends on [normal/test-utils]

Now, persumerably, dev/crate-client and normal/crate-client can be compiled with different configs, so ti seems unlikely that the compiler can magically unify dev/crate-client::Name with normal/crate-client::Name

5

I'm actually running cargo test in the root level / workspace. I guess it should both use dev mode for crate-client and crate-test-utils.

6

Is there a cfg directive that allows us to do:

#[debug]
struct Name {
  x: u64,
  #[cfg( ... only if not dev mode... )]
  y: u64,
  #[cfg( ... only if dev mode ... )]
  z: u64,
}

Then instead of the assert_eq!, do a println!

This would allow us to test to see if it indeed is dev-mode::client::Name vs normal-mode::client::Name

7 
struct Name {
  x: u64,
  #[cfg(not(debug_assertions))]
  y: u64,
  #[cfg(debug_assertions)]
  z: u64,
}
8

This is an issue raised up in rust source codebase, but seems not much response.
https://github.com/rust-lang/rust/issues/59305

9

Do you expect the compiler to compile crate-client twice with different flags ?

If yes => why should the two structs match up ?
If no => how do we get rid of the cyclic dependency of crates ?

10

I am facing such a compilation error as well. Maybe it's worth opening another issue for that topic.

11

Yes, please open a new topic.

12

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.