Add --build-plan for 'cargo build' #5301

mshal · 2018-04-05T19:49:45Z

With 'cargo build --build-plan', cargo does not actually run any
commands, but instead prints out what it would have done in the form of
a JSON data structure.

Fixes #3815

aturon · 2018-04-05T19:54:22Z

cc @aidanhs

matklad · 2018-04-11T09:32:47Z

Awesome @mshal! I really like how this looks now!

I think we need to be really careful not to expose internal implementation details of Cargo, and this approach achieves this almost perfectly. I especially like how BuildPlan is a just a bunch of PODs. However, the following things leak some information:

buildkey stores textual representation of various internal structures. It is intended to be used as opaque key, so this doesn't strictly matter, but perhaps there's a simple way to get more opaque id. For example, we could assign numerical ids to units, by lazily populating a HashMap<Unit, usize> map.
we expose target directory structure via various command-line options. I think this OK probably, as long as we document that precise outputs location are subject to change. I expect that, if a build systems wants to use a different directory structure, it can reliably post-process the build plan and substitute target dir with something else. Perhaps it makes sense to add a targer_dir field to build-plan itself, to make it easier to distinguish invariant source paths from potentially changeable target paths?
we expose links key. Is this really necessary? I think that we use it cargo mainly for user's convenience, and otherwise everything else works with unliked outputs from deps (not sure about this though, let's ask @alexcrichton).

Regarding the implementation itself, it looks great! We use slightly different code style in Cargo though, so you might want to rustup +stable component add rustfmt-preview and run rustfmt +stavle --skip-children $FILE for changed files.

It would also be great to have some tests for this as well! I think we should create a tests/testsuite/build_plan.rs file and add a couple of smoke test. Here's an example of a test for JSON output:

cargo/tests/testsuite/build.rs

Line 4024 in b0d65af

assert_that(

. Note how [..] and {..} are used as wildcards to match arbitrary strings/objects to get around platform specific variations.

add a rustfmt detail to CONTRIBUTING.md stealing from the info in #5301 (comment)

bors · 2018-04-12T00:30:05Z

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

djc · 2018-04-12T10:59:07Z

Sorry, I'm afraid my refactoring in #5348 has bitrotted this quite a bit. :(

What would be a nice side goal for this (though I hope that doesn't complicate it too much) is if cargo itself is refactored such that it goes through (a) generating the build plan, and then (b) executing from the build plan. That would make it more robust in the sense that we know the cargo build itself is not inadvertently relying on anything but the build plan.

That's not in this PR, as far as I can see, right?

mshal · 2018-04-18T23:53:49Z

buildkey stores textual representation of various internal structures. It is intended to be used as opaque key, so this doesn't strictly matter, but perhaps there's a simple way to get more opaque id. For example, we could assign numerical ids to units, by lazily populating a HashMap<Unit, usize> map.

I was trying to make the buildkey to be something human-readable, so for example you would be able to see that a "app_units v0.6.0 Target(lib) Profile(build) Target" depends on "num-traits v0.1.43 Target(lib) Profile(build) Target" and "serde v1.0.37 Target(lib) Profile(build) Target" by looking at the generated JSON output. This also gives the external build system some indication of what it is building, so it can use the key when displaying what it's building. Eg: "Now building app_units v0.6.0 Target(lib) Profile(build) Target". Note this doesn't need to be consistent among cargo versions, as long as the buildkey is unique for different modules (including host vs. target vs. build-script iterations of a particular cargo module) during a single 'cargo --build-plan' invocation. I'm happy to use another naming scheme though if there's a better way to get this information.

we expose target directory structure via various command-line options. I think this OK probably, as long as we document that precise outputs location are subject to change. I expect that, if a build systems wants to use a different directory structure, it can reliably post-process the build plan and substitute target dir with something else. Perhaps it makes sense to add a targer_dir field to build-plan itself, to make it easier to distinguish invariant source paths from potentially changeable target paths?

Sorry I don't quite follow this. What target are you referring to? Is this the --target flag in the json output? Or the self.target in the buildkey definition?

I don't think it matters if the output location changes, since the "outputs" field of the build plan explicitly lists where the file will be created. So if cargo decides things need to be in a different directory, a new 'cargo --build-plan' invocation will list a different output for a module, where the new file can be created.

we expose links key. Is this really necessary? I think that we use it cargo mainly for user's convenience, and otherwise everything else works with unliked outputs from deps (not sure about this though, let's ask @alexcrichton).

I'm pretty sure this is necessary, otherwise the external build system won't know where to create the symlink for the "installed" version of the file.

Regarding the implementation itself, it looks great! We use slightly different code style in Cargo though, so you might want to rustup +stable component add rustfmt-preview and run rustfmt +stavle --skip-children $FILE for changed files.

Ahh, thanks for the heads up! I've used this on the files I've changed, though I had to use '--toolchain stable' instead of '+stable'.

It would also be great to have some tests for this as well! I think we should create a tests/testsuite/build_plan.rs file and add a couple of smoke test.

Good idea, I'll add some tests to get at least some basic coverage.

mshal · 2018-04-18T23:55:30Z

What would be a nice side goal for this (though I hope that doesn't complicate it too much) is if cargo itself is refactored such that it goes through (a) generating the build plan, and then (b) executing from the build plan. That would make it more robust in the sense that we know the cargo build itself is not inadvertently relying on anything but the build plan.

That's not in this PR, as far as I can see, right?

I like that idea, but unfortunately that's a bit beyond my level of expertise at the moment. You are correct that it is not in this PR. Maybe we can file a followup issue? I'm not really sure what would be involved.

alexcrichton

I'm happy to use another naming scheme though if there's a better way to get this information.

Would it be possible perhaps to do rules name foo-h145135135? The stringified version may not be entirely lossless in terms of capturing all the nuances that Cargo has, but hashing everything will for sure catch everything. I'm not sure if that's too unreadable of a target though? We could certainly work to make the prefix string pretty human readable.

What target are you referring to? Is this the --target flag in the json output? Or the self.target in the buildkey definition?

Ah I think @matklad means things like CARGO_TARGET_DIR and such variables to tweak the output. I'd imagine, though, that the current implementation is fine. I see build plans as a sort of "build me a plan for this exact one invocation" rather than "build me a plan which is configurable at build-time in the same way Cargo is". For the latter case I think you'd want to generate multiple plans or just use Cargo.

I'm pretty sure this is necessary, otherwise the external build system won't know where to create the symlink for the "installed" version of the file.

Yeah this is something we'll definitely want, otherwise Cargo I believe will only generate files with unreadable hashes!

I think we'll probably eventually need some more treatment to handle build scripts but I'm fine to defer that to later!

alexcrichton · 2018-04-20T17:41:28Z

src/cargo/ops/cargo_rustc/build_plan.rs

+    program: String,
+    args: Vec<String>,
+    env: BTreeMap<String, String>,
+    cwd: String,


I think PathBuf implements Serialize, so perhaps that could be used here instead of String to avoid some unwraps and to_str?

Looks like PathBuf works fine for cwd- thanks!

matklad · 2018-04-21T10:06:44Z

I was trying to make the buildkey to be something human-readable, so for example you would be able to see that a "app_units v0.6.0 Target(lib) Profile(build) Target" depends on "num-traits v0.1.43 Target(lib) Profile(build) Target" and "serde v1.0.37 Target(lib) Profile(build) Target" by looking at the generated JSON output. This also gives the external build system some indication of what it is building, so it can use the key when displaying what it's building.

Hm, interesting! I think it makes sense to also make it possible to connect build plan with other pieces of JSON information: cargo metadata and cargo build --message-format=json. To do that, we could include PackageId and Target field, like we do for artifacts. Hm, perhaps we should just embed Artifact as a field of Module?

Yeah this is something we'll definitely want, otherwise Cargo I believe will only generate files with unreadable hashes!

I'm pretty sure this is necessary, otherwise the external build system won't know where to create the symlink for the "installed" version of the file.

I have a slight suspicion that we are not on the same page here, so let me ask a clarifying question:

Am I correct that links is not strictly required? That is, I think if one executes the build plan without links, everything just works because Cargo only ever uses stuff from the deps folder? That is, link is there strictly for user's convenience, so that they can ./target/debug/my-binary.

The external build system would probably want to put final artifacts elsewhere, so the link key is probably not to relevant for it?

alexcrichton · 2018-04-21T16:03:28Z

@matklad hm a good question. So I know a lot of artifacts are target/debug/deps/foo which get linked to target/debug/foo, but I think we've also got artifacts like target/debug/deps/bar-xxxxxxx which get linked to target/debug/bar. For those with hashes I think we need a links, right?

matklad · 2018-04-21T16:47:06Z

For those with hashes I think we need a links, right?

Hm, so I've made an experiment by disabling all linking, and looks like it is required at least for build scripts:

error: failed to run custom build command for `regex v0.2.10`
could not execute process `/home/matklad/projects/cargo/target/debug/build/regex-c000d0f4c53b8f51/build-script-build` (never executed)
warning: build failed, waiting for other jobs to finish...
error: build failed

alexcrichton · 2018-04-23T14:31:50Z

Heh interesting! We could probably fix Cargo to not actually require links, but I think we'd still want to keep it for the final artifact regardless

mshal · 2018-04-23T23:03:37Z

Would it be possible perhaps to do rules name foo-h145135135? The stringified version may not be entirely lossless in terms of capturing all the nuances that Cargo has, but hashing everything will for sure catch everything. I'm not sure if that's too unreadable of a target though? We could certainly work to make the prefix string pretty human readable.

In order to get the test cases working, I had to change the key to be something other than the buildkey, so I've tried to implement @matklad's HashMap suggestion. (The with_json() function doesn't seem to let me wildcard keys with things like "foo [..]", only values). I couldn't get it to work with Unit since we don't have a Unit available during the drain_the_queue() function where I call plan.update(), so I've left it as a buildkey String for now. If there's a good way to fix get_id() to use a Unit everywhere, I could use some suggestions. The previous key is available as "display_name" in the Module structure so it is more clear what it is used for.

I see build plans as a sort of "build me a plan for this exact one invocation" rather than "build me a plan which is configurable at build-time in the same way Cargo is". For the latter case I think you'd want to generate multiple plans or just use Cargo.

Yes, exactly. If the cargo configuration changes (via Cargo.toml changes, environment variable changes, etc), we'd run cargo --build-plan to generate a new plan.

Hm, interesting! I think it makes sense to also make it possible to connect build plan with other pieces of JSON information: cargo metadata and cargo build --message-format=json. To do that, we could include PackageId and Target field, like we do for artifacts. Hm, perhaps we should just embed Artifact as a field of Module?

Perhaps? It does look similar, though I don't have a full grasp of the overall architecture to know if they would easily be combined.

mshal · 2018-04-23T23:05:49Z

The new push includes:

A few basic test cases for --build-plan
A module_map to use integer keys for the modules
Separate display_name for the user-readable string of the module
Ran rustfmt & rebased

mshal · 2018-04-24T14:12:26Z

I forgot to ask:

Is there a way I can use serde's to_string_pretty() and still have it work with test cases? The with_json() function doesn't seem to like the fact that to_string_pretty() prints on multiple lines.
When usize is serialized, it gets serialized as a string when it's a key, but as an integer when it's in a Vec. For example, in BuildPlan I have modules: BTreeMap<usize, Module>, which ends up looking like this:

"0": { ... }

And inside the module, the deps: Vec show up like this:

"deps": [2, 3, 4]

It would be helpful if they were either both quoted, or both not quoted, if possible.

matklad · 2018-04-24T14:21:14Z

The with_json() function doesn't seem to like the fact that to_string_pretty() prints on multiple lines.

In Cargo, we guarantee that JSON does not have internal linebreaks. We need it because we use JSON object per line format

It would be helpful if they were either both quoted, or both not quoted, if possible.

JSON requires keys to be always quoted. If you use numeric keys, perhaps you can use an array instead of a {}?

matklad · 2018-04-24T14:26:17Z

src/cargo/core/compiler/build_plan.rs

+
+    pub fn add_output(&mut self, path: &PathBuf, link: &Option<PathBuf>) {
+        self.outputs.push(path.clone());
+        if link.is_some() {


This could be if let Some(ref link) = *link to avoid unwrap down the line.

matklad · 2018-04-24T14:28:03Z

src/cargo/core/compiler/build_plan.rs

+            .expect("unicode program string required")
+            .to_string()
+            .clone();
+        self.cwd = cmd.get_cwd().unwrap().to_path_buf();


I am not entirely sure we set cwd in call cases. Let's change cwd: PathBuf, to cwd: Option<PathBuf>,?

matklad · 2018-04-24T14:29:55Z

src/cargo/core/compiler/build_plan.rs

+                var.clone(),
+                value
+                    .as_ref()
+                    .expect("environment value required")


I think this expect might panic sometimes. We use None to signify that the environment variable should be cleared, and by default we inherit env vars.

matklad · 2018-04-24T14:33:14Z

src/cargo/core/compiler/build_plan.rs

+#[derive(Debug, Serialize)]
+pub struct BuildPlan {
+    module_map: BTreeMap<String, usize>,
+    modules: BTreeMap<usize, Module>,


I think we can make this modules: Vec<Module>, and then, in get_id, we could push a Module::default to this Vec. This will require derive(Default) as well.

matklad · 2018-04-24T14:46:11Z

src/cargo/core/compiler/context/mod.rs

+            "{} {} {} {:?}",
+            self.pkg, self.target, self.profile, self.kind
+        )
+    }


Let's switch to @alexcrichton suggestions with hashes? It could look like this I think:

impl<'a> Unit<'a> { pub fn buildkey(&self) -> String { #![allow(deprecated)] // for SipHash use std::hash::{Hash, Hasher, SipHasher}; let mut hasher = SipHasher::new_with_keys(0, 0); self.hash(&mut hasher); format!("{}-{}", self.pkg.name(), hasher.finish()) } }

Agreed with @matklad on this, getting all the info into the key through the hash I think would be best here to ensure we don't forget to include anything

matklad · 2018-04-24T14:47:29Z

src/cargo/core/compiler/build_plan.rs

+
+#[derive(Debug, Serialize)]
+struct Module {
+    display_name: String,


Instead of display_name, I suggest including

pub package_id: PackageId, pub target: Target,

I think this conflicts with the derive(Default) suggestion above, since PackageId and Target both don't have defaults. Or is there an easy way to set those somehow?

Separately, I don't think just PackageId and Target are sufficient for differentiating between a build script and its corresponding run action, right? Don't we need the Profile for that as well?

It's true they won't work with Default, yeah, but could Default be removed? Using PackageId, Target, and Profile more closely match what Cargo is internally doing and using to represent data structures which is probably the best way to go for now to ensure it's all lossless

Hmm, I'm not sure - the Default attribute came from the feedback above where we push a default Module in get_id(). Is there a better way to re-work that to get PackageId and such in there?

bors · 2018-04-27T23:49:22Z

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

mshal · 2018-05-01T20:31:32Z

I've addressed most of the review feedback. The remaining issues involve the display_name hashing and storing elements of Unit in the Module. I'm a bit stumped on how to resolve it with Default, and also how to get a Unit into the update() method so that we can call get_id() and update a Module's outputs.

I also updated the BuildPlan to include a list of inputs, so an external build system will know which files cargo accessed so it can determine if the plan is out of date with respect to the input Cargo.toml files. This seemed to be fairly straightforward, but this section should also be reviewed.

After rebasing to the latest master, I noticed that cargo can no longer build mozilla-central. It fails with:

error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to load source for a dependency on `serde_derive`

Caused by:
  Unable to update https://github.com/servo/serde?branch=deserialize_from_enums6#b8d39b01

Caused by:
  failed to update replaced source https://github.com/servo/serde?branch=deserialize_from_enums6#b8d39b01

Caused by:
  failed to parse manifest at `/home/mshal/mozilla-central-tmp/third_party/rust/serde/Cargo.toml`

Caused by:
  Feature `derive` depends on `serde_derive` which is not an optional dependency.
Consider adding `optional = true` to the dependency

I bisected it down to commit 4966f53. Ted poked around with it - it looks like it now finds the last dependency instead of the first, and serde lists serde_derive twice (once in dependencies and once in dev-dependencies), so that commit changes which one it tries to use.

mshal · 2018-05-02T14:02:46Z

Is there a better way to handle the tests in a cross-platform way than what I have? Right now they are listed as [cfg(unix)] due to the paths in the JSON output and '/' not matching '' on Windows. I also had to wildcard out some of the outputs because of the additional dSYM file in OSX, but I'd prefer if I could list the expected outputs for the platform somewhere and feed that into the expected JSON.

bors · 2018-05-02T14:41:36Z

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

alexcrichton · 2018-05-03T00:30:16Z

@mshal oh the issue about optional dependencies should be resolved by #5454, now landed on master

alexcrichton · 2018-05-03T00:31:52Z

tests/testsuite/build_plan.rs

+        .build();
+
+    assert_that(
+        p.cargo("build").arg("--build-plan"),


Ah one thing I've forgotten when reviewing is that we'll want the --build-plan argument to initially be unstable. This can be done by either renaming it to -Z build-plan or leaving it as this argument but also requiring -Z unstable-options to be passed to enable the argument

alexcrichton · 2018-05-03T00:32:59Z

src/cargo/core/compiler/build_plan.rs

+use serde_json;
+
+#[derive(Debug, Default, Serialize)]
+struct Module {


Would a better name for this perhaps be something like Compilation or Invocation? A "module" in Rust is pretty different from what this is I believe

bors · 2018-05-10T19:07:24Z

📌 Commit 4016bac has been approved by matklad

alexcrichton · 2018-05-10T19:08:23Z

@bors: r=matklad

bors · 2018-05-10T19:08:24Z

📌 Commit a071c3a has been approved by matklad

bors · 2018-05-10T19:55:08Z

⌛ Testing commit a071c3a with merge 13c258e...

Add --build-plan for 'cargo build' With 'cargo build --build-plan', cargo does not actually run any commands, but instead prints out what it would have done in the form of a JSON data structure. Fixes #3815

bors · 2018-05-10T20:37:31Z

☀️ Test successful - status-appveyor, status-travis
Approved by: matklad
Pushing 13c258e to master...

Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md

Update Cargo Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md

Unblocking PRs: - rust-lang/cargo#5535 - Ignore <tab> in libtest output. (unblocks rust-lang#50387) - rust-lang/cargo#5537 - Remove -Zno-trans test. (unblocks rust-lang#50615) - rust-lang/cargo#5540 - Fix tests when CARGO_TARGET_DIR is set. (unblocks self) Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5527 - Point Source Replacement to the Overriding Dependencies section - rust-lang/cargo#5533 - Detail how to run locally-built nightly cargo - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md

Update Cargo Unblocking PRs: - rust-lang/cargo#5535 - Ignore <tab> in libtest output. (unblocks rust-lang#50387) - rust-lang/cargo#5537 - Remove -Zno-trans test. (unblocks rust-lang#50615) - rust-lang/cargo#5540 - Fix tests when CARGO_TARGET_DIR is set. (unblocks self) Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5527 - Point Source Replacement to the Overriding Dependencies section - rust-lang/cargo#5533 - Detail how to run locally-built nightly cargo - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md

Unblocking PRs: - rust-lang/cargo#5535 - Ignore <tab> in libtest output. (unblocks rust-lang#50387) - rust-lang/cargo#5537 - Remove -Zno-trans test. (unblocks rust-lang#50615) - rust-lang/cargo#5540 - Fix tests when CARGO_TARGET_DIR is set. (unblocks self) Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5527 - Point Source Replacement to the Overriding Dependencies section - rust-lang/cargo#5533 - Detail how to run locally-built nightly cargo - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md

Update Cargo Unblocking PRs: - rust-lang/cargo#5535 - Ignore tab in libtest output. (unblocks #50387) - rust-lang/cargo#5537 - Remove -Zno-trans test. (unblocks #50615) - rust-lang/cargo#5540 - Fix tests when CARGO_TARGET_DIR is set. (unblocks self) Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5527 - Point Source Replacement to the Overriding Dependencies section - rust-lang/cargo#5533 - Detail how to run locally-built nightly cargo - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md The PR fixes #50640.

jonas-schievink · 2018-05-26T18:31:01Z

Does this need a tracking issue?

alexcrichton · 2018-05-27T19:54:38Z

Sure yeah! @jonas-schievink want to write one up?

jonas-schievink · 2018-05-27T20:12:11Z

Sure, opened #5579 to track this

alexcrichton · 2018-05-27T20:12:34Z

Awesome, thanks!

rust-highfive assigned matklad Apr 5, 2018

mshal mentioned this pull request Apr 5, 2018

Add --build-plan for 'cargo build' #4734

Closed

dwijnand mentioned this pull request Apr 11, 2018

add a rustfmt detail to CONTRIBUTING.md #5343

Merged

bors added a commit that referenced this pull request Apr 11, 2018

Auto merge of #5343 - dwijnand:contributing-fmt, r=matklad

4b8af3a

add a rustfmt detail to CONTRIBUTING.md stealing from the info in #5301 (comment)

alexcrichton reviewed Apr 20, 2018

View reviewed changes

mshal force-pushed the build-plan branch from c861702 to 3812661 Compare April 23, 2018 23:04

matklad reviewed Apr 24, 2018

View reviewed changes

alexcrichton mentioned this pull request May 1, 2018

Split Context into two types #5432

Merged

mshal force-pushed the build-plan branch from 3812661 to 4cdc57e Compare May 1, 2018 20:21

alexcrichton reviewed May 3, 2018

View reviewed changes

Fixup some minor review comments

a071c3a

alexcrichton force-pushed the build-plan branch from 4016bac to a071c3a Compare May 10, 2018 19:08

bors merged commit a071c3a into rust-lang:master May 10, 2018

ehuss mentioned this pull request May 12, 2018

Update Cargo rust-lang/rust#50696

Merged

ehuss mentioned this pull request May 15, 2018

Rollup of 11 pull requests rust-lang/rust#50747

Closed

jonas-schievink mentioned this pull request May 27, 2018

Tracking issue for build plan generation (--build-plan) #5579

Open

matklad mentioned this pull request Jul 29, 2018

Add CompileMode to Executor callbacks #5830

Merged

ehuss added this to the 1.28.0 milestone Feb 6, 2022

Add --build-plan for 'cargo build' #5301

Add --build-plan for 'cargo build' #5301

Conversation

mshal commented Apr 5, 2018

aturon commented Apr 5, 2018

matklad commented Apr 11, 2018

bors commented Apr 12, 2018

djc commented Apr 12, 2018

mshal commented Apr 18, 2018

mshal commented Apr 18, 2018

alexcrichton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

matklad commented Apr 21, 2018

alexcrichton commented Apr 21, 2018

matklad commented Apr 21, 2018

alexcrichton commented Apr 23, 2018

mshal commented Apr 23, 2018

mshal commented Apr 23, 2018

mshal commented Apr 24, 2018

matklad commented Apr 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Apr 27, 2018

mshal commented May 1, 2018

mshal commented May 2, 2018

bors commented May 2, 2018

alexcrichton commented May 3, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented May 10, 2018

alexcrichton commented May 10, 2018

bors commented May 10, 2018

bors commented May 10, 2018

bors commented May 10, 2018

jonas-schievink commented May 26, 2018

alexcrichton commented May 27, 2018

jonas-schievink commented May 27, 2018

alexcrichton commented May 27, 2018