Skip to content

Two different versions of a crate interacting leads to unhelpful error messages #22750

Closed
@huonw

Description

@huonw
Member

https://github.com/huonw/bad-error-messages-a contains a crate a. https://github.com/huonw/bad-error-messages-bc contains two crates, b and c.

  • a contains a trait Foo and a function test that requires that trait.
  • b depends on a specific revision (8b532f5, not the HEAD) of a and contains a type Bar that implements a::Foo.
  • c depends on a's HEAD (happens to be 84cfe230) and b, and tries to use b::Bar with a::test.

c fails to compile despite Bar "clearly" implementing Foo... it's even displayed in the docs!

Cloning https://github.com/huonw/bad-error-messages-bc and running cargo build in the root (which is c) gives

   Compiling a v0.0.1 (https://github.com/huonw/bad-error-messages-a#84cfe230)
   Compiling a v0.0.1 (https://github.com/huonw/bad-error-messages-a?rev=8b532f5#8b532f51)
   Compiling b v0.0.1 (file:///home/huon/projects/test-rust/error-messages/c)
   Compiling c v0.0.1 (file:///home/huon/projects/test-rust/error-messages/c)
src/lib.rs:5:5: 5:12 error: the trait `a::Foo` is not implemented for the type `b::Bar` [E0277]
src/lib.rs:5     a::test(b::Bar);
                 ^~~~~~~
error: aborting due to previous error

There's no indication of the fundamental problem from either rustdoc or rustc: that there's two different versions of a being used, meaning a#84cfe230::Foo and a#8b532f5::Foo are different. Bar only implements the latter, but in c, the name a refers to a#84cfe230 so a::test(...) requires the former. (Using name#rev to represent the crate with that version.)

There is an indication of the difference in the example above, since a is compiled twice, but that comes from cargo, not rustc. This issue is focusing on the fact that rustc itself does not give helpful errors and/or allow tools like cargo to control those errors.

It would be nice if rustc:

  • disambiguated ambiguous names, probably by filepath/name by default
  • allowed cargo to specify semantically relevant info for the disambiguation e.g. pass in the version/revision/..., so that rustc can print foo#0.2.3 instead of the filepath/name
  • detected errors that may be caused by ambiguous names and noted it explicitly, e.g. when there is a error involving an ambiguous crate print (once) some extra lines like "note: there's multiple versions of crate ... in use": along with a listing of the possibilities.

(NB. I've used cargo to construct this example because it is the easiest way I can get two different versions of a crate. This appears in rust-lang/rust's makefiles too, where the std test runner is called "std" internally, but links against another crate called "std", i.e. the conventional standard library.)

Activity

added
A-diagnosticsArea: Messages for errors, warnings, and lints
on Feb 24, 2015
Hoverbear

Hoverbear commented on Feb 24, 2015

@Hoverbear
Contributor

This bit me today with uuid! It took me a few minutes before I even understood that it wasn't "my" code that was giving this off.

Kimundi

Kimundi commented on Feb 27, 2015

@Kimundi
Member

Related, its also annoying if only crate local paths get emitted, like in backtraces.

We need a way for crates to identify themself uniquely, and not just by an identifier. Maybe a scheme like <crate foo #ef12f212>::bar::baz?

golddranks

golddranks commented on Mar 10, 2015

@golddranks
Contributor

I was bitten by this too.

Kimundi: Agreed for the need to unique identification. But then again, in some cases the local path tells more directly where the problem is. I wonder if there are cases where path is better and cases where a hash is better. Or maybe some kind of hybrid: If version information from cargo is available, use that. If not, if version control information is available, use commit SHA, and if no other information exists, use a path...?

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Sep 8, 2015
huonw

huonw commented on Sep 8, 2015

@huonw
MemberAuthor

Nominating for high priority. I think this is one of the main pain points people have when using cargo, and one of the major reasons for people complaining about cargo allowing multiple versions of a crate. It's usually easy to identify once you've seen it a few times, but it is a horribly confusing and annoying experience.

(Tagged with both compiler and tools since cargo presumably plays into this, but this is probably most relevant to the compiler subteam.)

@golddranks: the question of connecting semantically relevant info to crates is discussed a little in the issue. I think the best plan would external tools to pass in arbitrary strings connected to each crate, defaulting to the path, meaning rustc doesn't have to actually understand anything, just print strings (the compiler already has an --extern NAME=PATH argument that tools like cargo use, it could be extended to also allow --extern NAME#"ID"=PATH or something).

steveklabnik

steveklabnik commented on Sep 8, 2015

@steveklabnik
Member

I've also seen an increasing number of IRC questions about this.

On Sep 7, 2015, at 20:58, Huon Wilson notifications@github.com wrote:

Nominating for high priority. I think this is one of the main pain points people have when using cargo, and one of the major reasons for people complaining about cargo allowing multiple versions of a crate. It's usually easy to identify once you've seen it a few times, but it is a horribly confusing and annoying experience.

(Tagged with both compiler and tools since cargo presumably plays into this, but this is probably most relevant to the compiler subteam.)

@golddranks: the question of connecting semantically relevant info to crates is discussed a little in the issue. I think the best plan would external tools to pass in arbitrary strings connected to each crate, defaulting to the path, meaning rustc doesn't have to actually understand anything, just print strings (the compiler already has an --extern NAME=PATH argument that tools like cargo use, it could be extended to also allow --extern NAME#"ID"=PATH or something).


Reply to this email directly or view it on GitHub.

self-assigned this
on Sep 8, 2015
Manishearth

Manishearth commented on Sep 8, 2015

@Manishearth
Member

I'll take a crack at this

Manishearth

Manishearth commented on Sep 8, 2015

@Manishearth
Member

I think at the very least, for mismatched type and unimplemented trait errors, if we detect a crate mismatch, we should mention it. Any other such errors?

124 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.D-confusingDiagnostics: Confusing error or lint that should be reworked.D-crate-version-mismatchDiagnostics: Errors or lints caused be the use of two different crate versions.D-newcomer-roadblockDiagnostics: Confusing error or lint; hard to understand for new users.P-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @steveklabnik@seanmonstar@alexcrichton@zmanian@codyps

      Issue actions

        Two different versions of a crate interacting leads to unhelpful error messages · Issue #22750 · rust-lang/rust