-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Trait method cannot be imported from package when pulling dependency from git repository #128569
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
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
estebank
added a commit
to estebank/rust
that referenced
this issue
Aug 7, 2024
As per the case presented in rust-lang#128569, we should be showing the extra info even if auto-deref is involved.
estebank
added a commit
to estebank/rust
that referenced
this issue
Aug 10, 2024
As per the case presented in rust-lang#128569, we should be showing the extra info even if auto-deref is involved.
estebank
added a commit
to estebank/rust
that referenced
this issue
Aug 12, 2024
As per the case presented in rust-lang#128569, we should be showing the extra info even if auto-deref is involved.
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
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.
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library.
The parser library (TSPL) defines the
Parser
trait, with the byte code library (HVM) defining aCoreParser
that implements that trait through a macro from TSPL.Then, a third library does something like this, where
index
is a method from that trait:This works as expected if the dependencies in
Cargo.toml
are defined like this:If we change
TSPL
to use the version from the latest git commit like this:Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version
0.0.12
. We get an error and a warning:Notice that the compiler error tells us the function
index
has been found from theTSPL
package, and we do as the error message tells us (use TSPL::Parser
), but the compiler does not recognize the trait is being used even so.While writing this issue, I figured out the problem:
hvm
uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions ofTSPL
clash and the compiler does not compile. If we do something like this it works as expected:I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction.
Meta
rustc --version --verbose
:Backtrace
The text was updated successfully, but these errors were encountered: