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

Verify build-std resolve against original lockfile #13916

Closed

Conversation

adamgemmell
Copy link

What does this PR try to resolve?

Ensures that the resolve of the standard library when using build-std is a subset of the lockfile from the library source, as per discussion on rust-lang/wg-cargo-std-aware#38. It is a runtime version of the test added here: #13404

Fixes rust-lang/wg-cargo-std-aware#38

How should we test and review this PR?

It can be manually tested by running cargo build -Zbuild-std --target=[host] and seeing the command succeed. I'm not sure what behaviour can exercise the negative test case.

Additional information

Co-authored-by: Lawrence Tang lawrence.tang@arm.com

@rustbot
Copy link
Collaborator

rustbot commented May 15, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @weihanglo (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 (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added A-dependency-resolution Area: dependency resolution and the resolver A-lockfile Area: Cargo.lock issues A-workspaces Area: workspaces S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 15, 2024
@adamgemmell
Copy link
Author

adamgemmell commented May 15, 2024

r? @ehuss

(nvm, I forgot a file 🙃)

@rustbot rustbot assigned ehuss and unassigned weihanglo May 15, 2024
Co-authored-by: Lawrence Tang <lawrence.tang@arm.com>
@adamgemmell adamgemmell force-pushed the dev/adagem01/verify-std-lock branch from 4f5aa4d to eda17f3 Compare May 20, 2024 08:52
Comment on lines +173 to +174
let pkg_name = resolved_pkg.name().to_string();
let pkg_ver = resolved_pkg.version().to_string();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to to_string these?

@weihanglo
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 1, 2024
@bors
Copy link
Contributor

bors commented Aug 6, 2024

☔ The latest upstream changes (presumably #14358) made this pull request unmergeable. Please resolve the merge conflicts.

@weihanglo
Copy link
Member

Close. See rust-lang/wg-cargo-std-aware#38 (comment).

@weihanglo weihanglo closed this Aug 6, 2024
@adamgemmell adamgemmell deleted the dev/adagem01/verify-std-lock branch August 6, 2024 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dependency-resolution Area: dependency resolution and the resolver A-lockfile Area: Cargo.lock issues A-workspaces Area: workspaces S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider doing a forced lock of the standard library.
6 participants