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

Multiple max found #153

Closed
dtolnay opened this issue Jun 15, 2017 · 0 comments
Closed

Multiple max found #153

dtolnay opened this issue Jun 15, 2017 · 0 comments

Comments

@dtolnay
Copy link

dtolnay commented Jun 15, 2017

Looks like this is related to rust-lang/rust#42496.

   Compiling petgraph v0.4.4
warning[E0122]: trait bounds are not (yet) enforced in type definitions
   --> src/algo/mod.rs:169:1
    |
169 | type DfsSpaceType<G> where G: Visitable = DfsSpace<G::NodeId, G::Map>;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0034]: multiple applicable items in scope
   --> src/graph.rs:489:17
    |
489 |         assert!(Ix::max().index() == !0 || NodeIndex::end() != node_idx);
    |                 ^^^^^^^ multiple `max` found
    |
note: candidate #1 is defined in the trait `graph_impl::IndexType`
   --> src/graph.rs:47:5
    |
47  |     fn max() -> Self;
    |     ^^^^^^^^^^^^^^^^^
    = help: to disambiguate the method call, write `graph_impl::IndexType::max(...)` instead
note: candidate #2 is defined in the trait `std::cmp::Ord`
    = help: to disambiguate the method call, write `std::cmp::Ord::max(...)` instead

error[E0034]: multiple applicable items in scope
   --> src/graph.rs:526:17
    |
526 |         assert!(Ix::max().index() == !0 || EdgeIndex::end() != edge_idx);
    |                 ^^^^^^^ multiple `max` found
    |
note: candidate #1 is defined in the trait `graph_impl::IndexType`
   --> src/graph.rs:47:5
    |
47  |     fn max() -> Self;
    |     ^^^^^^^^^^^^^^^^^
    = help: to disambiguate the method call, write `graph_impl::IndexType::max(...)` instead
note: candidate #2 is defined in the trait `std::cmp::Ord`
    = help: to disambiguate the method call, write `std::cmp::Ord::max(...)` instead
ruuda added a commit to ruuda/pris that referenced this issue Jun 18, 2017
The current Rust nightly introduced a breaking change [1] that is
causing the build to fail for the nightly channel. The affected crate,
petgraph, has been updated [2] so it now compiles on nightly again, but
unfortunately I cannot use the latest version of that crate, because it
is a transitive dependency, and the crate which depends on it depends on
a version that Cargo considers semver-incompatible with the fixed crate.
The crate which depends on the crate broken by Rust nightly is lalrpop,
and a new version of it has been released that depends on a newer
version of petgraph which *is* semver-compatible with the fixed release.
However, upgrading to a newer version of lalrpop is also not possible,
because it requires a newer version of Rust. (Even after I contributed
a fix for that, and despite the changelog claiming to support Rust 1.13
now, it is still broken on 1.13 because of the lalrpop-snap crate.)

So now I am in a situation where I either have to drop support for Rust
1.13 and upgrade dependencies, or drop support for nightly Rust. The
least invasive change to my code at this point, is to drop support for
the nightly channel. Unfortunately that is only a temporary solution,
because the breakage is going to make it into beta and then stable. But
I am working on a hand-written parser anyway which will replace lalrpop,
so that dependency, and the dependency on petgraph, can hopefully be
dropped soon. That would maintain compatibility with Rust 1.13, and
restore compatibility with nightly at the same time.

A third option would be to ask the petgraph maintainers to release a
patch release of the older version that lalrpop depends on, which was
broken by Rust nightly. But for now the easiest thing for me to do to
get the build green, is to drop support for nightly Rust.

[1]: rust-lang/rust#42496
[2]: petgraph/petgraph#153
steveshogren added a commit to steveshogren/sqlpop that referenced this issue Dec 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant