-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
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
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
cc #80255 (different issue, but in the same general space of textually-identical, yet different, items) |
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
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.
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.
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 theCargo.toml
of the modified library still referenced thecrates.io
version.cargo tree
output looks like this (truncated):The problem being that the
Cargo.toml
indisplay-interface-parallel-gpio
was referencing thecrates.io
version ofdisplay-interface
instead of my local copy.This resulted in the compiler giving me the following error and warning:
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.
The text was updated successfully, but these errors were encountered: