-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
updated dependencies in library package #131574
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
This comment has been minimized.
This comment has been minimized.
compiler_builtins = "0.1.0" | ||
compiler_builtins = "0.1.133" | ||
cfg-if = { version = "1.0", features = ['rustc-dep-of-std'] } | ||
|
||
[target.'cfg(not(all(windows, target_env = "msvc")))'.dependencies] | ||
libc = { version = "0.2", default-features = false } | ||
libc = { version = "0.2.159", default-features = false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to pin these crates in only one place to reduce the number of places that need to be updated when bumping them. So libc
should be left as-is, compiler_builtins
can be left as-is or turned into only = "0.1"
. (This applies a few places).
We could probably also use workspace dependencies to make things more clear, but this is probably something that should be brought up on Zulip first since it could affect the ability of the crates to build in different workspaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The library is its own workspace now, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was mostly thinking about crates that wind up being part of different workspaces at different times through submodules or symlinks. Miri has some unusual things like that but I do doubt there is anything relevant in library/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was looking into this a bit more and found this 1f3be75#diff-02a067037f96954a7782700c9e368aca6229b3d8909031ec77fd67f035914853
While cargo workspaces normally enable dependencies of multiple targets
to be reused, for the standard library we do not want this reusing to
prevent conflicts between dependencies of the sysroot and of tools that
are built using this sysroot. For this reason we already use an unstable
cargo feature to ensure that any dependencies which would otherwise be
shared get a different -Cmetadata argument as well as using separate
build dirs.
It would be nice if we could figure this out somehow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just read through the post and I feel it would actually be nice. If it didn't fail on the CI / PR - x86_64-gnu-llvm-17, can it be approved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comment here still applies #131574 (comment), please change that back. Other than that I think the change looks fine (but it needs a rebase)
For the tidy error you'll have to update @rustbot author |
The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging. |
There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged. You can start a rebase with the following commands:
The following commits are merge commits: |
@tgross35 I have updated adler to adler2 and the tidy check is successful. I want to create a new pull request. |
Hey @tgross35 |
Updated some dependencies
All crates in the library package now have the most recent versions of their dependencies.
Also built each crate with the dependency updated to check it works properly.