Add `--all` flag to `cargo test` #3221

euclio · 2016-10-21T04:13:12Z

Work towards #2878.

This flag allows a user to test all members of a workspace by using cargo test --all. The command is also supported when using a virtual workspace manifest.

rust-highfive · 2016-10-21T04:13:25Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

alexcrichton · 2016-10-25T03:06:46Z

Thanks for the PR! Unfortunately I'll be pretty busy this week so it may take awhile to get back to this, but I haven't forgotten it!

alexcrichton

Ok, looking good! We may need a few cleanups along the way to really land this, but I think this is a great start.

alexcrichton · 2016-10-26T04:39:02Z

src/cargo/core/resolver/encode.rs

@@ -281,14 +281,15 @@ impl<'a, 'cfg> Encodable for WorkspaceResolve<'a, 'cfg> {

        let root = self.ws.members().max_by_key(|member| {
            member.name()
-        }).unwrap().package_id();
+        }).map(Package::package_id);


Hm were the changes in this file required to get tests to pass? Or just cleaning things up?

Yes, that panic is triggered when running test on a virtual manifest. It is currently prevented by the "error: manifest path ... is a virtual manifest, but this command requires running against an actual package in this workspace" error.

Ok, sounds good to me

alexcrichton · 2016-10-26T04:40:51Z

src/cargo/ops/cargo_compile.rs

+        Packages::All => ws.members()
+                           .map(|package| {
+                               let package_id = package.package_id();
+                               PackageIdSpec::from_package_id(package_id).to_string()


Instead of round-tripping through PackageIdSpec, perhaps the resolution to a list of local packages could be done sooner?

Where would be the right place to do that? I didn't want to place it too high up so that future --all commands could share this logic.

Maybe the concept of "all" could be plumbed farther down as an enum?

Plumbed down where? It makes sense to me to pass Packages down through resolve_dependencies but don't you still need to get the PackageIdSpecs of the workspace here to resolve the targets?

Yeah let's pass this down to resolve_dependencies, and perhaps that can also return a list of specs?

alexcrichton · 2016-10-26T04:43:11Z

src/cargo/ops/cargo_rustc/context.rs

@@ -28,7 +28,7 @@ pub struct Unit<'a> {
 pub struct Context<'a, 'cfg: 'a> {
    pub config: &'cfg Config,
    pub resolve: &'a Resolve,
-    pub current_package: PackageId,
+    pub current_package: Option<PackageId>,


Hm so I think this is a code smell we need to clean up (not your fault, a historical one). The concept of a "current package" is basically no longer valid in today's world of workspaces and such. Could this field get outright removed as part of this change?

I can try that, sure.

I think I need some clarification. What does "current package" mean in this context? Isn't it the package of the directory that we issue the compile in? Why is that not needed?

Yeah the intention is there really is not right question to what the "current package" means. It has different interpretations depending on where you are asking it from, so that's why I figure it'd be best to remove and we can answer that question on a case-by-case basis.

I see. Digging into this more, I'm noticing that the places that use Context don't have a Workspace available to pull a root package from (if one exists). So, doesn't making this an Option essentially handle this (i.e., a workspace either has a current package, or it's virtual, so it doesn't). Thank you for your patience :)

alexcrichton · 2016-10-26T04:44:22Z

src/cargo/ops/cargo_compile.rs

+        let root_package = try!(ws.current());
+        if spec.len() == 0 {
+            try!(generate_targets(root_package, &profiles, mode, filter, release));
+        }


This kinda sent me spinning for a bit. I think this if statement isn't necessary, right? It's implied to always be true given the above condition.

alexcrichton · 2016-10-26T04:44:52Z

src/cargo/ops/cargo_compile.rs

+            doc: Profile::default_doc(),
+            custom_build: Profile::default_custom_build(),
+        },
+    };


Hm this is somewhat worrisome to me. This is where I think we'll want to learn about the profiles from the workspace root crate instead of whatever the current crate happens to be.

Does the workspace have a root crate in a virtual manifest?

Not exactly yet, see #3249 :)

@matklad Awesome! I can rebase on top of your PR.

Ah yeah #3249 is exactly what I had in mind here

bors · 2016-11-02T00:31:34Z

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

Use a single profile set per workspace This aims to close #3206. I have not figured out how to do this 100% backward compatibly, that's why I want to discuss this separately, although a related PR (#3221) is already in flight. The problem is this: suppose that you have a workspace with two members, A and B and that A includes a profiles section and B does not. Now, mentally `cd` inside B and run `cargo build`. Today, Cargo will use a default profile. We want it to use a profile from A. So here the silent behavior switch will inevitably occur :( Looks like we can't detect this situation. So this PR just switches the behavior to always use root profiles, and to print a warning if a non-root package specifies profiles. Feel free to reuse it in any form for #3221 if that's convenient!

euclio · 2016-11-06T23:40:03Z

Rebased. Hopefully will get a chance to work on this more later this week.

alexcrichton · 2016-11-08T16:58:55Z

src/cargo/ops/cargo_compile.rs

@@ -92,8 +99,10 @@ pub enum CompileFilter<'a> {

 pub fn compile<'a>(ws: &Workspace<'a>, options: &CompileOptions<'a>)
                   -> CargoResult<ops::Compilation<'a>> {
-    for key in try!(ws.current()).manifest().warnings().iter() {
-        try!(options.config.shell().warn(key))
+    if let Some(root_package) = ws.current_opt() {


Random drive-by comment, but could this actually iterate over all members of the workspace? That's the intention here, at least

bors · 2016-11-11T02:10:30Z

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

euclio · 2016-11-16T21:06:18Z

Rebased, and ready for another round of review, @alexcrichton

alexcrichton

Looking great!

alexcrichton · 2016-11-17T19:55:10Z

src/cargo/core/resolver/encode.rs

            }
-
-            Some(encodable_resolve_node(id, self.resolve))


Hm ok to sanity check this (changes to resolve are very subtle).

I don't think this change is needed, right? The change above (unwrap -> map) is purely for cargo test against an empty virtual manifest, right? If there exists any crates at all (e.g. ids is a non-empty list) then I'd hope there's at least one workspace member.

alexcrichton · 2016-11-17T19:56:06Z

src/cargo/ops/cargo_compile.rs

-                                .collect::<CargoResult<Vec<_>>>()?;
-
-    let pair = resolve_dependencies(ws,
+    let resolve = resolve_dependencies(ws,
                                         source,


Some indentation to match up here

alexcrichton · 2016-11-17T19:59:27Z

src/cargo/ops/cargo_compile.rs

-        for p in spec {
-            pkgids.push(resolve_with_overrides.query(&p)?);
+        for p in spec.iter() {
+            pkgids.push(resolve_with_overrides.query(&p.to_string())?);


I think this can just be:

pkgids.push(p.query(resolve_with_overrides.iter()));

(avoid going through a string)

alexcrichton · 2016-11-17T20:01:27Z

src/cargo/ops/cargo_compile.rs

        }
    } else {
+        let root_package = ws.current()?;
+        generate_targets(root_package, profiles, mode, filter, release)?;


I think this was special cased above to get these errors before the resolution process happened (which may involve downloads and such). Perhaps that logic could still be special cased?

Putting this logic the old way caused my tests to fail, but I'm not sure why.

alexcrichton · 2016-11-17T20:02:56Z

src/cargo/ops/cargo_rustc/context.rs

-            self.config.extra_verbose()
+        self.ws.current_opt().map_or(false, |p| *pkg == *p.package_id())
+            || pkg.source_id().is_path()
+            || self.config.extra_verbose()


I think this can be updated to just the clause:

pkg.source_id().is_path() || self.config.extra_verbose()

Well technically actually, we should show warnings for all workspace members, not not all path dependencies.

alexcrichton · 2016-11-17T20:04:39Z

src/cargo/ops/cargo_rustc/context.rs

@@ -417,7 +416,8 @@ impl<'a, 'cfg> Context<'a, 'cfg> {
        // we don't want to link it up.
        if src_dir.ends_with("deps") {
            // Don't lift up library dependencies
-            if unit.pkg.package_id() != &self.current_package && !unit.target.is_bin() {
+            if self.ws.current_opt().map_or(false, |p| unit.pkg.package_id() != p.package_id())


I think here we can actually just test:

if !unit.pkg.package_id().source_id().is_path() && !unit.target.is_bin() { // ... }

That is, all path dependencies should hit the code path of Some below

er actually, we should replace the current_package check with a check if the crate is in the workspace rather than all path dependencies.

What's the correct way to check this?

ws.members().find(|&p| p == unit.pkg).is_some() causes test failures.

Hm yeah that should work, but is that not working? What do the test failures look like?

Hm, on a second look I think I might have just been reversing the conditional. Pushed a fix.

alexcrichton · 2016-11-17T20:06:47Z

src/cargo/ops/cargo_rustc/context.rs

@@ -273,7 +272,7 @@ impl<'a, 'cfg> Context<'a, 'cfg> {

    /// Returns the appropriate directory layout for either a plugin or not.
    pub fn layout(&self, unit: &Unit) -> LayoutProxy {
-        let primary = unit.pkg.package_id() == &self.current_package;
+        let primary = self.ws.current_opt().map_or(false, |p| unit.pkg.package_id() == p.package_id());


I think this can be replaced with:

let primary = is_member_of_current_workspace(self, unit);

alexcrichton · 2016-11-17T20:07:57Z

src/cargo/ops/cargo_rustc/job_queue.rs

-        let profile = cx.lib_profile(&cx.current_package);
+        let profile = cx.ws.current_opt().map_or_else(Profile::default, |p| {
+            cx.lib_profile(p.package_id()).to_owned()
+        });


The package argument here to lib_profile is actually ignored (long story), so let's just go ahead and remove that argument and then we can avoid the workaround here.

alexcrichton · 2016-11-17T20:09:09Z

src/cargo/ops/cargo_rustc/mod.rs

-                          unit.pkg.package_id() != &cx.current_package);
+                          cx.ws.current_opt().map_or(false, |p| {
+                              *p.package_id() != *unit.pkg.package_id()
+                          }));


Wow I have absolutely no clue what this clause is doing (the old one).

Let's just replace it though with, like above, a test whether the package is in the current workspace.

Same as above.

euclio · 2016-11-29T19:47:16Z

Still working on this, haven't had much time for open source lately! Hoping to finish up by the weekend.

alexcrichton · 2016-11-30T00:32:55Z

Ah no worries, let me know if you need any help getting it over the finish line!

bors · 2016-12-02T01:55:36Z

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

euclio · 2016-12-02T22:31:52Z

@alexcrichton Most comments addressed, I commented on the remaining issues.

alexcrichton · 2016-12-08T19:12:28Z

Sorry for taking awhile to get back to this! I just want to dig into the "is a member" issue a bit and then we should be able to land this.

euclio · 2016-12-08T22:45:44Z

@alexcrichton, no problem! Everything should be addressed now. There are failing tests, but those are due to #879.

alexcrichton · 2016-12-08T23:50:08Z

@bors: r+

Awesome, thanks!

bors · 2016-12-08T23:50:09Z

📌 Commit addbb7e has been approved by alexcrichton

bors · 2016-12-08T23:50:14Z

⌛ Testing commit addbb7e with merge fec03d3...

Add `--all` flag to `cargo test` Work towards #2878. This flag allows a user to test all members of a workspace by using `cargo test --all`. The command is also supported when using a virtual workspace manifest.

bors · 2016-12-09T01:10:36Z

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing fec03d3 to master...

@euclio

Add test for --package and virtual manifest closes #3194 The issue was actually fixed by #3221 (thanks @euclio !), so let's just add a test (a copy of `virtual_works` basically).

khuey · 2017-02-07T08:42:08Z

Was it expected that this changed cargo's behavior so that tests of dependent lib crates are no longer dropped in the target/debug folder?

alexcrichton · 2017-02-07T17:49:20Z

@khuey no I think that may have been accidental! Oddly enough #3660 was just reported as well and I believe that bug was fixed in #3478, could you test beta/nightly to see if they're working for you?

khuey · 2017-02-07T18:31:20Z

It's still broken on tip (de2919f)

khuey · 2017-02-07T20:56:14Z

Woops, I was testing the wrong binary. It is indeed fixed on tip. I'll bisect for a fix cset.

alexcrichton · 2017-02-07T20:57:02Z

Ok, thanks for checking!

khuey · 2017-02-07T21:18:47Z

It was indeed fixed by 3cbf141.

The regression is present in the cargo that ships with rustc 1.15. That's not a big deal for me (I just won't use it) but something you may want to be aware of.

alexcrichton · 2017-02-08T00:47:28Z

Sure thing, thanks for the heads up regardless

Fix logic for determining prefer-dynamic for a dylib. The logic for determining if a dylib should use `prefer-dynamic` used to be something like "do not use prefer-dynamic if it is the current package". The current logic has a strange behavior where it works as intended if there is only one package in the workspace, but a workspace with multiple packages will always use `prefer-dynamic`. Instead of using `current_opt`, which isn't a good concept to use in a workspace, I switched this to be "primary" (a package selected on the command-line). **History** * 9879a0a Initial prefer-dynamic behavior. * #3221 changed to the faulty logic (see comments at #3221 (comment)). I think there was some confusion there. * #3478 fixed the logic for one of the changed conditions, but not the one for prefer-dynamic

rust-highfive assigned brson Oct 21, 2016

alexcrichton reviewed Oct 26, 2016

View reviewed changes

brson assigned alexcrichton and unassigned brson Nov 3, 2016

matklad mentioned this pull request Nov 3, 2016

Use a single profile set per workspace #3249

Merged

euclio force-pushed the test-all branch from ea515af to 37af534 Compare November 6, 2016 23:39

alexcrichton reviewed Nov 8, 2016

View reviewed changes

euclio force-pushed the test-all branch from 37af534 to 3faca82 Compare November 16, 2016 21:05

alexcrichton reviewed Nov 17, 2016

View reviewed changes

matklad mentioned this pull request Nov 21, 2016

Renaming the project root dir invalidates compilation cache #3273

Closed

Luthaf mentioned this pull request Nov 25, 2016

Implement feature: adjustable maximum displacement in Monte-Carlo lumol-org/lumol#52

Merged

euclio force-pushed the test-all branch 2 times, most recently from fc8e469 to 12331db Compare December 2, 2016 22:28

euclio added 5 commits December 8, 2016 16:11

avoid panic when virtual workspace has no members

25518da

add --all flag to cargo-test

62c0497

remove current_package from context

0ae3a2b

pass Packages into resolve dependencies

c368d6a

show warnings for all members of the workspace

81e5c76

replace current_opt with membership check

addbb7e

euclio force-pushed the test-all branch from 12331db to addbb7e Compare December 8, 2016 22:41

alexcrichton added the relnotes Release-note worthy label Dec 8, 2016

bors merged commit addbb7e into rust-lang:master Dec 9, 2016

This was referenced Dec 9, 2016

cargo check #3296

Merged

cargo fails if it can't find optional dependencies, even if corresponding feature not enabled #3369

Merged

matklad mentioned this pull request Dec 12, 2016

Add test for --package and virtual manifest #3385

Merged

alexcrichton mentioned this pull request Feb 14, 2017

Possible regression bug in workspaces handling #3698

Closed

ehuss mentioned this pull request Feb 25, 2019

Cap lints at warn when cargo installing #6647

Closed

dwijnand mentioned this pull request Feb 25, 2019

cargo install should use --cap-lints #3453

Closed

ehuss mentioned this pull request Mar 11, 2021

Fix logic for determining prefer-dynamic for a dylib. #9252

Merged

ehuss added this to the 1.15.0 milestone Feb 6, 2022

Add --all flag to cargo test #3221

Add --all flag to cargo test #3221

Conversation

euclio commented Oct 21, 2016

rust-highfive commented Oct 21, 2016

alexcrichton commented Oct 25, 2016

alexcrichton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

euclio Oct 26, 2016 • edited Loading

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

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 Nov 2, 2016

euclio commented Nov 6, 2016

Choose a reason for hiding this comment

bors commented Nov 11, 2016

euclio commented Nov 16, 2016

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

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

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

euclio commented Nov 29, 2016

alexcrichton commented Nov 30, 2016

bors commented Dec 2, 2016

euclio commented Dec 2, 2016

alexcrichton commented Dec 8, 2016

euclio commented Dec 8, 2016 • edited Loading

alexcrichton commented Dec 8, 2016

bors commented Dec 8, 2016

bors commented Dec 8, 2016

bors commented Dec 9, 2016

khuey commented Feb 7, 2017

alexcrichton commented Feb 7, 2017

khuey commented Feb 7, 2017

khuey commented Feb 7, 2017

alexcrichton commented Feb 7, 2017

khuey commented Feb 7, 2017

alexcrichton commented Feb 8, 2017

Add `--all` flag to `cargo test` #3221

Add `--all` flag to `cargo test` #3221

euclio Oct 26, 2016 •

edited

Loading

euclio commented Dec 8, 2016 •

edited

Loading