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

incompatible types when using re-exports of the same crate from different crates (different paths) #105277

Open
dustbort opened this issue Dec 4, 2022 · 3 comments
Labels
C-bug Category: This is a bug. needs-triage-legacy Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged.

Comments

@dustbort
Copy link

dustbort commented Dec 4, 2022

I tried this code:

let item = sickle_builder::types::time::Date::from_calendar_date(
    2020,
    sickle_builder::types::time::Month::January,
    1,
)?;
let y: i32 = item.year();
let m: tiberius::time::time::Month = item.month();
let d: u8 = item.day();
let date: tiberius::time::Date = tiberius::time::time::Date::from_calendar_date(y, m, d)?;

I expected to see this happen: No error

Instead, this happened:

error[E0308]: `?` operator has incompatible types
  --> sickle-query/src/mssql_queryable.rs:53:21
   |
53 |                     tiberius::time::time::Date::from_calendar_date(y, m, d)?
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `tiberius::time::Date`, found struct `sickle_builder::types::time::Date`
   |
   = note: `?` operator cannot convert from `sickle_builder::types::time::Date` to `tiberius::time::Date`

sickle_query::types::time and tiberius::time are re-exports of the time crate. For multiple reasons, these may be different versions with different features and are not be assumed to be the same. However, it seems that rustc is detecting that they are the same crate, and then "forgets" the path or assumes the wrong path on line 53. But though the path is explicitly given on both the left and right hand sides of the assignment, so there is no ambiguity.

Confirmed this for nightly with cargo +nightly build --workspace --all-targets --all-features

Note: This seems different than #102882, because I am explicitly stating the paths of which re-export to use, and am not making assumptions that they are the same. rustc seems to arbitrarily pick/unify/dedup a different re-export than what is explicitly stated on one side of the assignment, then fails to do the same with the other side.

Meta

rustc --version --verbose:

rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: x86_64-unknown-linux-gnu
release: 1.65.0
LLVM version: 15.0.0
Backtrace

No backtrace; it doesn't build.

@dustbort dustbort added the C-bug Category: This is a bug. label Dec 4, 2022
@albertlarsan68
Copy link
Member

What is the output of cargo tree --duplicates --workspace ?

@dustbort
Copy link
Author

dustbort commented Dec 5, 2022

@albertlarsan68 It outputs nothing. I also tried cargo tree --duplicates --workspace --all-features with same result.

@dustbort
Copy link
Author

dustbort commented Dec 5, 2022

It's also interesting that I tried using std::mem::transmute to see if rustc is really looking up the wrong definition for the RHS, and it is, because I got an error that the two structs are different sizes on the LHS and RHS. The error still shows the RHS coming from the sickle_builder crate instead of tiberius.
For example:

let date: tiberius::time::Time = unsafe { std::mem::transmute(tiberius::time::time::Time::from_hms_micro(hour, minute, second, microsecond)?) };

@ChrisDenton ChrisDenton added the needs-triage-legacy Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged. label Jul 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. needs-triage-legacy Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged.
Projects
None yet
Development

No branches or pull requests

3 participants