-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Implement the [patch] section of the manifest #4123
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
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @matklad |
|
Note that this shouldn't actually get merged until rust-lang/rfcs#1969 is merged, and I still need to update |
|
☔ The latest upstream changes (presumably #4118) made this pull request unmergeable. Please resolve the merge conflicts. |
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've just given a really quick skim, and looks like all the tests test replace scenario, where we augment with the same version we already have. Would be nice to have some tests for second and third scenario from the RFC!
tests/augment.rs
Outdated
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.
Hm, baz is not mentioned anywhere else in the tests?
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.
Oh this is used to route registry requests (e.g. updating the index) to the local version and not crates.io itself.
|
Sure yeah, pushed up some more tests. Some drafts of docs are up but they still need serious reworking (this is just whatever work I had done from awhile ago) |
src/cargo/core/manifest.rs
Outdated
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.
Hm, specifying augment as a Dependency (that is, a constraint on possible versions) does not feel semantically right. What does it mean to augment a registry with foo 1.0.*?
Should we add a constraint that you must explicitelly add a =x.y.z constraint to the augment? This seems better from the theoretical pov, but I don't see any real benefits except perhaps for the better readability:
[augment.crates-io]
xml-rs = { git = "https://github.com/aturon/xml-rs", branch = "servo-fix" }vs
[augment.crates-io]
xml-rs = { version = "0.9.2", git = "https://github.com/aturon/xml-rs", branch = "servo-fix" }That is, I am a bit unsure about
Cargo will unconditionally resolve all entries in the [augment] section to precise dependencies, encoding them all in the lock file whether they're used or not.
section of the RFC. Should cargo really resolve entries in augment? What if it finds several versions of [augment] (it's not possible with git source, but may be possible with some theoretical other), which one should it choose?
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.
Ah, I see that we just bail if augment resolves to more than one summary!
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 the intention here was that the syntax of this section is the same as [dependencies], so we'd just store it as a vanilla Dependency. Then it only makes sense to augment with git sources or path sources, which only ever return one summary anyway, so it'd suffice for that.
src/cargo/core/workspace.rs
Outdated
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.
Am I correct that augment is only allowed in the root of the workspace? We should probably enforce this.
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.
It is, yeah. I'll look to adding enforcement.
src/cargo/core/registry.rs
Outdated
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.
Looks suspicious... It should be either augments.insert(url, deps) or augments.entry().or_insert().extend(deps).
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 feel like I originally had this as extend and later changed it to this. I'll update the code.
src/cargo/core/registry.rs
Outdated
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.
Let's add something like match_ignore_source to dependency, just to keep all related logic in one place? It's interesting that we need something similar for overrides (only_match_name thing), but the implementation there uses a different strategy.
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 old overrides are... odd...
In any case though the suggestion sounds good!
src/cargo/core/registry.rs
Outdated
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 think in this branch we should bail with an error if !augments.is_empty().
src/cargo/core/registry.rs
Outdated
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 could add a sanity check here that we find at most one matching augment.
src/cargo/core/resolver/encode.rs
Outdated
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 think we can use null object pattern and store augment: Augment, using an empty augment instead of None. Serialization can be tweaked separately:
#[serde(default)]
#[serde(skip_if = "Augment::is_empty")]
augment: Augment
src/cargo/core/resolver/encode.rs
Outdated
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.
Could use is_empty().
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.
Probably irrelevant if we go with null object here :)
src/cargo/ops/resolve.rs
Outdated
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.
Hm, what if previous contains some old augments, which are no longer present in the current Cargo.toml?
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 think these'll just get dropped later, but I've added a test to assert this as well.
src/doc/manifest.md
Outdated
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.
Regarding docs, we have an overwhelming number of options to override a package from crates.io:
augmentreplace- path overrides
- path dependencies
- vendoring
Perhaps we could create a new section "using non crates io depedendencies", which gives a flow chart style guide of choosing a right tool for the problem?
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.
Sounds plausible to me! I plan to focus on these docs once we land the RFC
tests/cargotest/support/mod.rs
Outdated
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 am curious, is this to improve compile times? Does it really help measurably?
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.
It started off as that yeah, I was astounded at how long it took a "hello world" cargo test to compile so was randomly trying things to push down compile times, none of it ever ended up working though :(
|
☔ The latest upstream changes (presumably #4259) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I've updated with documentation and a renaming to |
|
Alright, building Cargo locally for testing brand-new features sounds reasonable (at least in terms of compile times compared to building rustc). I’m not sure how to use it, though. Can I just copy |
Update to cargo 0.21.0-nightly (eb6cf012a 2017-07-02) Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17780) <!-- Reviewable:end -->
|
Copying |
|
@matklad When building Servo you don’t typically run Cargo directly, so it’s a little more involved. But I’ll figure something out. |
|
Hm, I wonder if I think you can even |
|
Interesting. But I think I’d rather have |
Update to cargo 0.21.0-nightly (eb6cf012a 2017-07-02) Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17780) <!-- Reviewable:end -->
Update to cargo 0.21.0-nightly (eb6cf012a 2017-07-02) Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17780) <!-- Reviewable:end -->
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c --HG-- extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear extra : subtree_revision : 5adb79e9d2a0446949f4ca8211496d96b41e648f
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c
rust-lang/cargo#4123 added the [patch] section of the manifest
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b rust-lang/cargo#4123 added the `[patch]` section of the manifest
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b rust-lang/cargo#4123 added the `[patch]` section of the manifest
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c
Changelog:
Version 1.21.0 (2017-10-12)
==========================
Language
--------
- [You can now use static references for literals.][43838]
Example:
```rust
fn main() {
let x: &'static u32 = &0;
}
```
- [Relaxed path syntax. Optional `::` before `<` is now allowed in all contexts.][43540]
Example:
```rust
my_macro!(Vec<i32>::new); // Always worked
my_macro!(Vec::<i32>::new); // Now works
```
Compiler
--------
- [Upgraded jemalloc to 4.5.0][43911]
- [Enabled unwinding panics on Redox][43917]
- [Now runs LLVM in parallel during translation phase.][43506]
This should reduce peak memory usage.
Libraries
---------
- [Generate builtin impls for `Clone` for all arrays and tuples that
are `T: Clone`][43690]
- [`Stdin`, `Stdout`, and `Stderr` now implement `AsRawFd`.][43459]
- [`Rc` and `Arc` now implement `From<&[T]> where T: Clone`, `From<str>`,
`From<String>`, `From<Box<T>> where T: ?Sized`, and `From<Vec<T>>`.][42565]
Stabilized APIs
---------------
[`std::mem::discriminant`]
Cargo
-----
- [You can now call `cargo install` with multiple package names][cargo/4216]
- [Cargo commands inside a virtual workspace will now implicitly
pass `--all`][cargo/4335]
- [Added a `[patch]` section to `Cargo.toml` to handle
prepublication dependencies][cargo/4123] [RFC 1969]
- [`include` & `exclude` fields in `Cargo.toml` now accept gitignore
like patterns][cargo/4270]
- [Added the `--all-targets` option][cargo/4400]
- [Using required dependencies as a feature is now deprecated and emits
a warning][cargo/4364]
Misc
----
- [Cargo docs are moving][43916]
to [doc.rust-lang.org/cargo](https://doc.rust-lang.org/cargo)
- [The rustdoc book is now available][43863]
at [doc.rust-lang.org/rustdoc](https://doc.rust-lang.org/rustdoc)
- [Added a preview of RLS has been made available through rustup][44204]
Install with `rustup component add rls-preview`
- [`std::os` documentation for Unix, Linux, and Windows now appears on doc.rust-lang.org][43348]
Previously only showed `std::os::unix`.
Compatibility Notes
-------------------
- [Changes in method matching against higher-ranked types][43880] This may cause
breakage in subtyping corner cases. [A more in-depth explanation is available.][info/43880]
- [rustc's JSON error output's byte position start at top of file.][42973]
Was previously relative to the rustc's internal `CodeMap` struct which
required the unstable library `libsyntax` to correctly use.
- [`unused_results` lint no longer ignores booleans][43728]
[42565]: rust-lang/rust#42565
[42973]: rust-lang/rust#42973
[43348]: rust-lang/rust#43348
[43459]: rust-lang/rust#43459
[43506]: rust-lang/rust#43506
[43540]: rust-lang/rust#43540
[43690]: rust-lang/rust#43690
[43728]: rust-lang/rust#43728
[43838]: rust-lang/rust#43838
[43863]: rust-lang/rust#43863
[43880]: rust-lang/rust#43880
[43911]: rust-lang/rust#43911
[43916]: rust-lang/rust#43916
[43917]: rust-lang/rust#43917
[44204]: rust-lang/rust#44204
[cargo/4123]: rust-lang/cargo#4123
[cargo/4216]: rust-lang/cargo#4216
[cargo/4270]: rust-lang/cargo#4270
[cargo/4335]: rust-lang/cargo#4335
[cargo/4364]: rust-lang/cargo#4364
[cargo/4400]: rust-lang/cargo#4400
[RFC 1969]: rust-lang/rfcs#1969
[info/43880]: rust-lang/rust#44224 (comment)
[`std::mem::discriminant`]: https://doc.rust-lang.org/std/mem/fn.discriminant.html
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c UltraBlame original commit: 380ad1bfb187a075e540ffaf07e2c104d6c00a13
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c UltraBlame original commit: 380ad1bfb187a075e540ffaf07e2c104d6c00a13
…07-02) (from servo:cargoup); r=nox,SimonSapin Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash. Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment) Source-Repo: https://github.com/servo/servo Source-Revision: d403f404382c66485d9744787ce021556be59d6c UltraBlame original commit: 380ad1bfb187a075e540ffaf07e2c104d6c00a13
This is an implementation of RFC 1969 which adds a new section to top-level
manifests:
[patch]. This section allows you to augment existing sources withnew versions of crates, possibly replacing the versions that already exist in
the source. More details about this feature can be found in the RFC itself.