-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
refactor(toml): Decouple logic from schema #13080
Conversation
r? @weihanglo (rustbot has picked a reviewer for you, use r? to override) |
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.
Mostly LGTM. Thank you!
@@ -670,6 +670,98 @@ pub struct TomlProfile { | |||
pub trim_paths: Option<TomlTrimPaths>, | |||
} | |||
|
|||
impl TomlProfile { | |||
/// Overwrite self's values with the given profile. | |||
pub fn merge(&mut self, profile: &Self) { |
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.
Profile layering was one of the few pieces of logic I kept in the schema, assuming its general enough / decoupled enough from cargo policies.
How is thing general enough? Do we have any possible use case outside cargo?
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.
From what I understand of profiles, the merging is inherent to their definition, so if someone wants to do process the manifest, they'll need it.
I know its a bit dubious about why this when other things don't get included. The biggest motivation is that this is tightly coupled to the struct definition and keeping them close is important to avoid forgetting to merge new fields. The reason I felt this as justifiable was that it is very direct without special logic.
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.
so if someone wants to do process the manifest, they'll need it.
I can hardly find a case for purely merging profile without any profile inheritance logic involved.
keeping them close is important to avoid forgetting to merge new fields
However, I understand and agree to this reason. We can always iterate later on. Thank you!
One thing worth calling out is that free functions sometimes are hard to find. By grouping methods under an item I can get a better auto-completion experience whey typing |
This is a given if we still want to do #12801. A lot of this logic is too tightly coupled to the internals of cargo to be able to split out without a lot of other work first (if ever) |
@bors r+ Thank you again for the hard work! |
☀️ Test successful - checks-actions |
Update cargo 25 commits in 26333c732095d207aa05932ce863d850fb309386..58fb23140972092a12f7011d17a7db1d99e3eacf 2023-11-28 20:07:39 +0000 to 2023-12-02 14:15:16 +0000 - test(install): use TCP connection instead of thread sleep (rust-lang/cargo#13099) - test(mdman): Switch to snapbox (rust-lang/cargo#13098) - Include declared list of features in fingerprint for `-Zcheck-cfg` (rust-lang/cargo#13012) - chore(deps): update compatible (rust-lang/cargo#13083) - chore(ci): Always update gix packages together (rust-lang/cargo#13093) - chore(deps): update rust crate windows-sys to 0.52 (rust-lang/cargo#13089) - refactor(toml): Decouple logic from schema (rust-lang/cargo#13080) - Have cargo add --optional <dep> create a <dep> = "dep:<dep> feature (rust-lang/cargo#13071) - Add `--public` for `cargo add` (rust-lang/cargo#13046) - chore(deps): update rust crate toml_edit to 0.21.0 (rust-lang/cargo#13088) - chore(deps): update rust crate rusqlite to 0.30.0 (rust-lang/cargo#13087) - test(trim-paths): exercise with real world debugger (rust-lang/cargo#13091) - Fixed uninstall a running binary failed on Windows (rust-lang/cargo#13053) - chore(deps): update rust crate itertools to 0.12.0 (rust-lang/cargo#13086) - Add more options to registry test support. (rust-lang/cargo#13085) - Don't filter on workspace members when scraping doc examples (rust-lang/cargo#13077) - Remove the outdated comment (rust-lang/cargo#13076) - fix(resolver): Remove unused public-deps error handling (rust-lang/cargo#13036) - Fixes error count display is different when there's only one error left (rust-lang/cargo#12484) - fix: reorder `--remap-path-prefix` flags for `-Zbuild-std` (rust-lang/cargo#13065) - remove jobserver env var in some tests (rust-lang/cargo#13072) - doc: clarify different target has different set of `CARGO_CFG_*` values (rust-lang/cargo#13069) - docs: remove review capacity notice in PR template (rust-lang/cargo#13070) - chore(deps): update rust crate openssl to 0.10.60 [security] (rust-lang/cargo#13068) - fix(resolver): De-prioritize no-rust-version in MSRV resolver (rust-lang/cargo#13066) r? ghost
Update cargo 27 commits in 26333c732095d207aa05932ce863d850fb309386..623b788496b3e51dc2f9282373cf0f6971a229b5 2023-11-28 20:07:39 +0000 to 2023-12-02 18:10:03 +0000 - docs(book): make old title anchorable (rust-lang/cargo#13102) - Revert "chore(deps): update rust crate openssl to 0.10.60 [security]" (rust-lang/cargo#13101) - test(install): use TCP connection instead of thread sleep (rust-lang/cargo#13099) - test(mdman): Switch to snapbox (rust-lang/cargo#13098) - Include declared list of features in fingerprint for `-Zcheck-cfg` (rust-lang/cargo#13012) - chore(deps): update compatible (rust-lang/cargo#13083) - chore(ci): Always update gix packages together (rust-lang/cargo#13093) - chore(deps): update rust crate windows-sys to 0.52 (rust-lang/cargo#13089) - refactor(toml): Decouple logic from schema (rust-lang/cargo#13080) - Have cargo add --optional <dep> create a <dep> = "dep:<dep> feature (rust-lang/cargo#13071) - Add `--public` for `cargo add` (rust-lang/cargo#13046) - chore(deps): update rust crate toml_edit to 0.21.0 (rust-lang/cargo#13088) - chore(deps): update rust crate rusqlite to 0.30.0 (rust-lang/cargo#13087) - test(trim-paths): exercise with real world debugger (rust-lang/cargo#13091) - Fixed uninstall a running binary failed on Windows (rust-lang/cargo#13053) - chore(deps): update rust crate itertools to 0.12.0 (rust-lang/cargo#13086) - Add more options to registry test support. (rust-lang/cargo#13085) - Don't filter on workspace members when scraping doc examples (rust-lang/cargo#13077) - Remove the outdated comment (rust-lang/cargo#13076) - fix(resolver): Remove unused public-deps error handling (rust-lang/cargo#13036) - Fixes error count display is different when there's only one error left (rust-lang/cargo#12484) - fix: reorder `--remap-path-prefix` flags for `-Zbuild-std` (rust-lang/cargo#13065) - remove jobserver env var in some tests (rust-lang/cargo#13072) - doc: clarify different target has different set of `CARGO_CFG_*` values (rust-lang/cargo#13069) - docs: remove review capacity notice in PR template (rust-lang/cargo#13070) - chore(deps): update rust crate openssl to 0.10.60 [security] (rust-lang/cargo#13068) - fix(resolver): De-prioritize no-rust-version in MSRV resolver (rust-lang/cargo#13066)
refactor: Clarify PackageId constructor names ### What does this PR try to resolve? From #13080 > I would love to see eithe rename this function or have a doc comment on it. It always puzzle me what pure means. From my experience, `new` is more normally a name for more direct construction when there are alternatives ### How should we test and review this PR? ### Additional information
This is a step towards moving `PackageIdSpec` into `schema` as manifests need it as part of rust-lang#12801. While I didn't take this approach in rust-lang#13080, that was largely how core these functions are / how pervasive their use is.
This is a step towards moving `PackageIdSpec` into `schema` as manifests need it as part of rust-lang#12801. While I didn't take this approach in rust-lang#13080, that was largely how core these functions are / how pervasive their use is.
What does this PR try to resolve?
This tries to decouple cargo logic from the schemas so we can split the schemas out into a separate crate for #12801
Profile layering was one of the few pieces of logic I kept in the schema, assuming its general enough / decoupled enough from cargo policies.
How should we test and review this PR?
Each step is broken down into its own commit for easier analysis
Additional information