Cyclic dev-dependencies can cause confusing errors

[mikhailOK]

Describe the problem you are trying to solve
Cargo detects cyclic dependencies, but allows crates to depends on each other in [dev-dependencies]. This can lead to a confusing error message

Here is a minimal repro: https://github.com/mikhailOK/bad-cargo-cyclic-dependency

Two crates, crate1 and crate2
crate2 depends on crate1, but crate1 has crate2 in [dev-dependencies]

crate1/src/lib.rs:

#[derive(PartialEq, Eq, Debug)]
pub struct Value {}

#[cfg(test)]
mod tests {
    #[test]
    pub fn mismatched_types() {
        assert_eq!(crate2::return_value(), crate::Value {});
    }
}

crate2/src/lib.rs:

pub fn return_value() -> crate1::Value {
    crate1::Value {}
}

cargo test -p crate1 fails with a compilation error:

error[E0308]: mismatched types
 --> crate1/src/lib.rs:8:9
  |
8 |         assert_eq!(crate2::return_value(), crate::Value {});
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `crate1::Value`, found struct `Value`
  |
  = note: expected type `crate1::Value`
             found type `Value`

Describe the solution you'd like
My question is, is there a valid use case for this kind of cyclic dependencies?
If there isn't, can this case be a cargo error?

Notes

[ehuss]

I think there are some use cases based on other issues (primarily #4242, also #3745, #1686, #432). In my testing, I don't see how people use it (since I get similar errors that you got), but apparently some people use it.

[Nemo157]

They work fine in external tests as they are linked against crate1-as-library (so there is no real circular dependency), the problem above is caused because internal tests are using both crate1-as-library via crate2 and crate1-for-tests which are completely separate libraries built from the same source code.