refactor(toml): Split out an explicit step to resolve Cargo.toml
#13693
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This also removes duplicated inheritance and one of them specifying the wrong field.
Returning a `&String` is unusual but this keeps things easier on both sides.
This will make it easier to evaluate what needs to be resolved in the future.
We can't have validation depend on `TomlManifest::resolved_lints` yet because we need to pull out the resolving of deps first.
Normally, I prefer directly constructing something but I feel this works better in this case so I can limit a lot of work that is coupled to a `package` being present. Since we still directly construct, just with `None`, I think this still works.
I'm somewhat tempted to flatten the function call. The parallel between the package an virtual-manifest cases would help to keep them in sync.
Collaborator
|
r? @weihanglo rustbot has assigned @weihanglo. Use |
rustbot
added
A-manifest
Muscraft
approved these changes
Apr 3, 2024
Member
Muscraft
left a comment
Muscraft
left a comment
There was a problem hiding this comment.
Thanks!
This makes stuff much easier to understand
Member
|
@bors r+ |
Contributor
bors
added
S-waiting-on-bors
Contributor
Contributor
|
☀️ Test successful - checks-actions |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 6, 2024
Update cargo 9 commits in 0637083df5bbdcc951845f0d2eff6999cdb6d30a..28e7b2bc0a812f90126be30f48a00a4ada990eaa 2024-04-02 23:55:05 +0000 to 2024-04-05 19:31:01 +0000 - refactor(toml): Decouple target discovery from Target creation (rust-lang/cargo#13701) - Don't depend on `?` affecting type inference in weird ways (rust-lang/cargo#13706) - test(metadata): Show behavior with TOML-specific types (rust-lang/cargo#13703) - fix: adjust tracing verbosity in list_files_git (rust-lang/cargo#13704) - doc: comments on `PackageRegistry` (rust-lang/cargo#13698) - Switch to using gitoxide by default for listing files (rust-lang/cargo#13696) - Allow precise update to prerelease. (rust-lang/cargo#13626) - refactor(toml): Split out an explicit step to resolve `Cargo.toml` (rust-lang/cargo#13693) - chore(deps): update rust crate base64 to 0.22.0 (rust-lang/cargo#13675) r? ghost
This was referenced Jul 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR try to resolve?
This builds on #13664 and #13666. Currently, once we have deserialized
Cargo.toml, we pass it to a large machinery (to_real_manifest,to_virtual_manifest) so thatCargo.tomlis resolvedSummaryis createdManifestis createdThis splits out the resolving of
Cargo.tomlwhich is mostly workspace inheritance today.While splitting logic conjoined like this can be a bit messy in the short term, the hope is that overall this makes the logic easier to follow (more condensed, focused sections to view; more explicit inputs/outputs).
In particular, I hope that this will make it clearer and easier to shift more logic into the resolving step, specifically the inferring of build targets for #13456.
How should we test and review this PR?
This is broken up into very small steps in the hope that it makes it easier to analyze a step.
Additional information