Skip to content

rustc is using three versions of rand #57724

Closed
#62026
Closed
rustc is using three versions of rand#57724
#62026
Labels
E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Description

@scottmcm
scottmcm
opened on Jan 18, 2019

I noticed this scrolling by while "Building stage0 compiler artifacts" today:

   Compiling rand_pcg v0.1.1
   Compiling rand v0.6.1
   Compiling flate2 v1.0.6
   Compiling rand v0.4.3
   Compiling rand v0.5.5
   Compiling winapi-util v0.1.1

Optimistically flagging E-easy

Activity

  1. scottmcm
    added
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    on Jan 18, 2019
  2. scottmcm
    changed the title [-]rustc is using two versions of rand[/-] [+]rustc is using three versions of rand[/+] on Jan 18, 2019

  3. JohnTitor commented on Jan 18, 2019

    @JohnTitor
    JohnTitor
    on Jan 18, 2019
    Member

    @scottmcm I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?

  4. ishitatsuyuki commented on Jan 18, 2019

    @ishitatsuyuki
    ishitatsuyuki
    on Jan 18, 2019
    Contributor

    @JohnTitor You will need to look into each dependency that depends on rand (by searching through Cargo.lock), check if they have a newer version that depends on new rand, and finally use cargo update -p <crate> to upgrade those crates.

  5. JohnTitor commented on Jan 18, 2019

    @JohnTitor
    JohnTitor
    on Jan 18, 2019
    Member

    @ishitatsuyuki Thanks! When I checked, it seems each rand version is used.

  6. ishitatsuyuki commented on Jan 18, 2019

    @ishitatsuyuki
    ishitatsuyuki
    on Jan 18, 2019
    Contributor

    Yeah, it's natural that they are all used, and you could try to eliminate those crates using old rand by upgrading or refactoring. That said, there isn't much drawback with an older rand, so in that case this issue can be just closed.

  7. JohnTitor commented on Jan 18, 2019

    @JohnTitor
    JohnTitor
    on Jan 18, 2019
    Member

    Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?

  8. hellow554 commented on Jan 18, 2019

    @hellow554
    hellow554
    on Jan 18, 2019
    Contributor

    @ishitatsuyuki but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)

  9. JohnTitor commented on Jan 18, 2019

    @JohnTitor
    JohnTitor
    on Jan 18, 2019
    Member

    Uh, would it be better to fix?

  10. hellow554 commented on Jan 18, 2019

    @hellow554
    hellow554
    on Jan 18, 2019
    Contributor

    Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue @JohnTitor :)

  11. JohnTitor commented on Jan 18, 2019

    @JohnTitor
    JohnTitor
    on Jan 18, 2019
    Member

    Okay, I want to try to fix. For instance, crossbeam-channel depends on rand v0.5.5, how can I update or refactor this?

  12. hellow554 commented on Jan 18, 2019

    @hellow554
    hellow554
    on Jan 18, 2019
    Contributor

    That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?

  13. Aaron1011 commented on Jan 18, 2019

    @Aaron1011
    Aaron1011
    on Jan 18, 2019
    Contributor

    For future reference, running cargo tree -d from src/rustc is an easy way to identify the source of all duplicates.

  14. JohnTitor commented on Jan 19, 2019

    @JohnTitor
    JohnTitor
    on Jan 19, 2019
    Member

    Thanks @Aaron1011 ! I got this tree(gist).
    I updated parking_lot, but rustc-rayon v0.1.1 is latest and depends on rand v0.4.3(https://crates.io/crates/rustc-rayon).
    What should I do?

  15. scottmcm commented on Jan 20, 2019

    @scottmcm
    scottmcm
    on Jan 20, 2019
    MemberAuthor

    @hellow554 I'm not on compiler (or core), so don't take my word on this one 🙂

    @JohnTitor It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe ask someone on rayon first.) Also, it seems that rustc-rayon hasn't been updated in 6+ months, so they'd probably appreciate a PR to upgrade it to newer upstream.

  16. 11 remaining items

  17. Centril
    added 2 commits that reference this issue on Jun 7, 2019

    Rollup merge of rust-lang#61597 - lnicola:bump-rand, r=alexcrichton

    88c452e

    Rollup merge of rust-lang#61597 - lnicola:bump-rand, r=alexcrichton

    1938247

  18. lnicola commented on Jun 8, 2019

    @lnicola
    lnicola
    on Jun 8, 2019
    Member

    I tried to fix a part of this in #61597, but it didn't come out as planned. There is dependency and license whitelist that needs to be updated.

    I think just running cargo update leaves only one usage of rand 0.4 via ammonia and mdbook 1 (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.

  19. mati865 commented on Jun 8, 2019

    @mati865
    mati865
    on Jun 8, 2019
    Member

    Last time I checked mdbook and rustc-rayon were the only thing preventing of rand 0.4, otherwise I'd fix it already.
    We are working on removing it but it's blocked on releasing new version of mdbook.

  20. lnicola commented on Jun 8, 2019

    @lnicola
    lnicola
    on Jun 8, 2019
    Member

    I think rustc-rayon goes away after a cargo update, so that one might be easy to fix.

    I don't know how dependencies are updated across the rust repository. Is it just that most of them are for the tools, not for std and rustc? Does somebody run cargo update from time to time? And why does the tidy license check fail on bors on my PR, but not on Travis or on my computer?

  21. mati865 commented on Jun 8, 2019

    @mati865
    mati865
    on Jun 8, 2019
    Member

    So rustc-rayon released new version since.

    Is it just that most of them are for the tools, not for std and rustc?

    Correct, dependencies of everything that is created by dist are tracked by single Cargo.lock.

    Does somebody run cargo update from time to time?

    Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50.

    And why does the tidy license check fail on bors on my PR, but not on Travis or on my computer?

    I think it should error when you run ./x.py build.

  22. mati865 commented on Jun 8, 2019

    @mati865
    mati865
    on Jun 8, 2019
    Member

    Also you can run the same image that found the error (x86_64-gnu-llvm-6.0 in this case) by using these steps https://github.com/rust-lang/rust/blob/master/src/ci/docker/README.md

  23. Manishearth
    added a commit that references this issue on Jul 2, 2019

    Rollup merge of rust-lang#62026 - mati865:deps, r=alexcrichton

    e988c42
  24. bors
    closed this as completedin #62026on Jul 8, 2019
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

    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions