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

Confusing diagnostics when pulling the same crate from different sources #81659

Closed
andresovela opened this issue Feb 2, 2021 · 2 comments · Fixed by #128786
Closed

Confusing diagnostics when pulling the same crate from different sources #81659

andresovela opened this issue Feb 2, 2021 · 2 comments · Fixed by #128786
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-crate-version-mismatch Diagnostics: Errors or lints caused be the use of two different crate versions. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@andresovela
Copy link

andresovela commented Feb 2, 2021

Source thread in URLO

I was working with a library crate that I forked to modify locally in my project. In the Cargo.toml of the binary I referenced my local copy of the modified library, but the Cargo.toml of the modified library still referenced the crates.io version.

cargo tree output looks like this (truncated):

├── display-interface v0.4.0 (/Users/andresovela/dev/rust/embedded/my-app/crates/display-interface)
├── display-interface-parallel-gpio v0.4.1 (/Users/andresovela/dev/rust/embedded/my-app/crates/display-interface/parallel-gpio)
│   ├── byte-slice-cast v0.3.5
│   ├── display-interface v0.4.0
├── ili9486 v0.1.0 (/Users/andresovela/dev/rust/embedded/my-app/crates/ili9486-rs)
│   ├── display-interface v0.4.0 (/Users/andresovela/dev/rust/embedded/my-app/crates/display-interface)
│   ├── display-interface-parallel-gpio v0.4.1 (/Users/andresovela/dev/rust/embedded/my-app/crates/display-interface/parallel-gpio) (*)

The problem being that the Cargo.toml in display-interface-parallel-gpio was referencing the crates.io version of display-interface instead of my local copy.

This resulted in the compiler giving me the following error and warning:

error[E0599]: no method named `send_commands` found for struct `PGPIO8BitInterface<nrf52832_hal::gpio::Pin<Output<PushPull>>, P0_28<Output<PushPull>>, P0_04<Output<PushPull>>>` in the current scope
  --> src/main.rs:44:23
   |
44 |     ili9486_interface.send_commands(display_interface::DataFormat::U8(&data));
   |                       ^^^^^^^^^^^^^ method not found in `PGPIO8BitInterface<nrf52832_hal::gpio::Pin<Output<PushPull>>, P0_28<Output<PushPull>>, P0_04<Output<PushPull>>>`
   |
   = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
   |
4  | use display_interface::WriteOnlyDataCommand;
   |

warning: unused import: `display_interface::WriteOnlyDataCommand`
 --> src/main.rs:4:5
  |
4 | use display_interface::WriteOnlyDataCommand;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It would have been much much better if the compiler noticed that there is conflict in crate versions somehow. Maybe if it detects that the trait name exists but it comes from a different crate or something? Unfortunately I'm not well versed in the compiler internals, but I think this case could be definitely improved.

@camelid camelid added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 3, 2021
@camelid
Copy link
Member

camelid commented Feb 3, 2021

cc #80255 (different issue, but in the same general space of textually-identical, yet different, items)

@dhardy
Copy link
Contributor

dhardy commented Feb 22, 2022

Another example is running this in the playground:

// Problem: playground uses rand_pcg v0.2.1 crate which is outdated and depends
// on rand_core 0.5, while rand v0.8.4 depends on rand_core 0.6, hence two
// versions of the SeedableRng trait exist.

use rand::{Rng, SeedableRng};

fn main() {
    let mut rng = rand_pcg::Pcg32::seed_from_u64(123);
    println!("{}", rng.gen::<i32>());
}

@WaffleLapkin WaffleLapkin added the D-crate-version-mismatch Diagnostics: Errors or lints caused be the use of two different crate versions. label Apr 28, 2023
tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
…r=fee1-dead

Detect multiple crate versions on method not found

When a type comes indirectly from one crate version but the imported trait comes from a separate crate version, the called method won't be found. We now show additional context:

```
error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope
 --> multiple-dep-versions.rs:8:10
  |
8 |     Type.foo();
  |          ^^^ method not found in `Type`
  |
note: there are multiple different versions of crate `dependency` in the dependency graph
 --> multiple-dep-versions.rs:4:32
  |
4 | use dependency::{do_something, Trait};
  |                                ^^^^^ `dependency` imported here doesn't correspond to the right crate version
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that was imported
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that is needed
5 |     fn foo(&self);
  |        --- the method is available for `dep_2_reexport::Type` here
```

Fix rust-lang#128569, fix rust-lang#110926, fix rust-lang#109161, fix rust-lang#81659, fix rust-lang#51458, fix rust-lang#32611. Follow up to rust-lang#124944.
tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
…r=fee1-dead

Detect multiple crate versions on method not found

When a type comes indirectly from one crate version but the imported trait comes from a separate crate version, the called method won't be found. We now show additional context:

```
error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope
 --> multiple-dep-versions.rs:8:10
  |
8 |     Type.foo();
  |          ^^^ method not found in `Type`
  |
note: there are multiple different versions of crate `dependency` in the dependency graph
 --> multiple-dep-versions.rs:4:32
  |
4 | use dependency::{do_something, Trait};
  |                                ^^^^^ `dependency` imported here doesn't correspond to the right crate version
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that was imported
  |
 ::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:4:1
  |
4 | pub trait Trait {
  | --------------- this is the trait that is needed
5 |     fn foo(&self);
  |        --- the method is available for `dep_2_reexport::Type` here
```

Fix rust-lang#128569, fix rust-lang#110926, fix rust-lang#109161, fix rust-lang#81659, fix rust-lang#51458, fix rust-lang#32611. Follow up to rust-lang#124944.
@bors bors closed this as completed in 9b318d2 Aug 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-crate-version-mismatch Diagnostics: Errors or lints caused be the use of two different crate versions. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants