Skip to content
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

Add host dependency path via -L for cargo_test. #4447

Merged
merged 4 commits into from Aug 31, 2017
Merged

Add host dependency path via -L for cargo_test. #4447

merged 4 commits into from Aug 31, 2017

Conversation

lucaskolstad
Copy link
Contributor

Proc-macro crates' dependencies in the host dependency directory cannot
be found when running cargo test with the --target {target} flag
set as reported in #4224. This adds the host dependency directory to the
search path to find those missing dependencies with -L when building tests
and adds a test case that fails before and passes after this patch.

A new function find_host_deps(..) is added to accomplish this which can
determine the path of the host dependencies directory from within
run_doc_tests(..) where the missing library search path is needed.

Fixes #4224
Fixes #4254

Modeled after a similar patch: a298346

Concerns

The test case seems to require a non-local crate from crates.io to example the failure before this patch. Couldn't make it fail with simply another local subcrate, but if others think it's possible that'd be great. This means that during tests for the cargo project itself that this test case actually downloads and compiles a crate, which I don't think any other tests do and is obviously not ideal and is perhaps even unacceptable. I've used the base64 crate pretty arbitrarily, but which crate it is really doesn't matter to test the case's content. So if anyone knows a tiny or empty crate on crates.io to use instead that'd speed this up and if someone can figure out how to make it fail before this patch is applied without downloading an external crate that would help as well.

Also, I'm not 100% confident about the find_host_deps(..) style and whether it's the best way to find the host dependencies directory with just the TestOptions and Compilation structs available since I'm new to this project. Any comments are appreciated.

Proc-macro crates' dependencies in the host dependency directory cannot
be found when running `cargo test` with the `--target {target}` flag
set. This adds the host dependency directory with -L when building tests
and a test case that fails before and passes after this patch.

A new function find_host_deps(..) is added to accomplish this which can
determine the path of the host dependencies directory from within
run_doc_tests(..) where the missing library search path is needed.

Fixes #4224
Fixes #4254
@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (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.

@@ -144,6 +145,8 @@ fn run_doc_tests(options: &TestOptions,
p.arg("--test").arg(lib)
.arg("--crate-name").arg(&crate_name);

p.arg("-L").arg(&host_deps);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It occurred to me that this line may need to be further down to put the host directory after the others? Does the ordering of the -L options mean this is buggy despite passing tests?

tests/test.rs Outdated
proc-macro = true

[dependencies]
base64 = "^0.6"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Throughout a number of other tests you'll see calls to Package::new(..).publish() which allow having a "fake registry" during testing without actually pulling in a dependency from crates.io, perhaps that can be used here instead?

@@ -198,3 +201,24 @@ fn run_doc_tests(options: &TestOptions,
}
Ok((Test::Doc, errors))
}

fn find_host_deps(options: &TestOptions, compilation: &Compilation) -> OsString {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of being calculated here, could this perhaps be a field of the Compilation returned?

@alexcrichton
Copy link
Member

Thanks so much for the PR!

This patch removes the addition of the find_host_deps() function by
adding a host_deps_output field to the Compilation struct instead. The
test case is altered to not use an external crate from crates.io but
instead use the Package.publish(..) method.
@lucaskolstad
Copy link
Contributor Author

lucaskolstad commented Aug 30, 2017

I've removed the find_host_deps(..) function and added a host_deps_output field to the Compilation struct instead that is similar to the deps_output field. I noted that the field is somewhat identical to plugins_dylib_path and is initialized in the same place with the same value even. But I was thinking this is used for different reasons and maybe it's best to be different? Not sure if you want me to just use plugins_dylib_path and rename it or something.

Also, there is a confusing problem with the Package::new(..).publish() method you suggested and I switched to. It seems to make the test case no longer actually test the case! When I comment out the lines in run_doc_tests(..) where the host deps directory linkage is added, it still passes! However, if I add a base64 dependency to proc_macro_dep/Cargo.toml and an extern crate base64 in proc_macro_dep/src/lib.rs, it WILL test the case again and commenting out the lines causes a failure.

No idea what is going on with that tbh. Seems I genuinely might need an external crates.io crate... or maybe I'm just confused.

@alexcrichton
Copy link
Member

Hm can you gist the error you see with the base64 crate? #4224 seems to indicate the failure is when you cargo test a proc-macro crate itself?

Also yeah actually, let's stick to using plugins_dylib_path or just renaming that to host_deps_output!

@lucaskolstad
Copy link
Contributor Author

lucaskolstad commented Aug 30, 2017

Here is an explanatory gist with 1. the exact lines commented out, 2. the exact code for the altered test case, and 3. the error output.

I'm not sure, does this mean the dep_of_proc_macro_dep third crate needs a dependency to be able to test the case?

@lucaskolstad
Copy link
Contributor Author

I tried adding a dependency below dep_of_proc_macro_dep in the same way using Package::new(..).publish() and specifying a Cargo.toml and lib.rs for dep_of_proc_macro_dep that externs the dependency and it just won't fail. With and without commented out lines in the source, I have never seen it fail unless adding an external crate like base64 still.

The plugins_dylib_path field on Compilation is removed because it is
identical to host_deps_output, it is only used in one easily replaced
location, and because host_deps_output is a more general name that
includes its new usage location in cargo_test.rs as well while better
matching the corresponding deps_output field.

Also de-indents erroneously indented lines in a test case.
@lucaskolstad
Copy link
Contributor Author

lucaskolstad commented Aug 31, 2017

I've made the choice and pushed a commit to remove the plugins_dylib_path field entirely and replaced it with host_deps_output in the single place it is used. I think host_deps_output is more general and has a more clear relationship to the deps_output field when used in places like run_doc_tests(..).

This should not affect any of the discussion above about the weird external vs local crate problem in the test case though.

@alexcrichton
Copy link
Member

Oh I think I see what's going on, try doing:

Package::new("foo", "0.1.0").publish();
Package::new("bar", "0.1.0")
    .dep("foo", "0.1")
    .file("src/lib.rs", "extern crate foo;")
    .publish();

and then have the procedural macro depend on bar?

Minor change causes the test to actually test the case instead of always
passing regardless of the fix that adds the host dependency directory to
the library search path.
@lucaskolstad
Copy link
Contributor Author

lucaskolstad commented Aug 31, 2017

You're right that did it! Thank you so much for helping me figure all this out.

If the CI testing passes, I think this PR is done then. Let me know if you want me to squash the last little commit or make any other changes.

@alexcrichton
Copy link
Member

@bors: r+

Nice!

Nah leaving as is is fine by me :)

@bors
Copy link
Collaborator

bors commented Aug 31, 2017

📌 Commit 95c6e68 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Aug 31, 2017

⌛ Testing commit 95c6e68 with merge f519d3d...

bors added a commit that referenced this pull request Aug 31, 2017
…e, r=alexcrichton

Add host dependency path via -L for cargo_test.

Proc-macro crates' dependencies in the host dependency directory cannot
be found when running `cargo test` with the `--target {target}` flag
set as reported in #4224. This adds the host dependency directory to the
search path to find those missing dependencies with -L when building tests
and adds a test case that fails before and passes after this patch.

A new function `find_host_deps(..)` is added to accomplish this which can
determine the path of the host dependencies directory from within
`run_doc_tests(..)` where the missing library search path is needed.

Fixes #4224
Fixes #4254

Modeled after a similar patch: a298346

**Concerns**

The test case seems to require a non-local crate from crates.io to example the failure before this patch. Couldn't make it fail with simply another local subcrate, but if others think it's possible that'd be great. This means that during tests for the cargo project itself that this test case actually downloads and compiles a crate, which I don't think any other tests do and is obviously not ideal and is perhaps even unacceptable. I've used the base64 crate pretty arbitrarily, but which crate it is really doesn't matter to test the case's content. So if anyone knows a tiny or empty crate on crates.io to use instead that'd speed this up and if someone can figure out how to make it fail before this patch is applied without downloading an external crate that would help as well.

Also, I'm not 100% confident about the `find_host_deps(..)` style and whether it's the best way to find the host dependencies directory with just the `TestOptions` and `Compilation` structs available since I'm new to this project. Any comments are appreciated.
@bors
Copy link
Collaborator

bors commented Aug 31, 2017

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

@bors bors merged commit 95c6e68 into rust-lang:master Aug 31, 2017
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Sep 2, 2017
This includes rust-lang/cargo#4447 which fixes
a bug in Cargo that is needed to fix
rust-lang#44237.
bors added a commit to rust-lang/rust that referenced this pull request Sep 2, 2017
Update cargo

This includes rust-lang/cargo#4447 which fixes a bug in Cargo that is needed to fix #44237.

r? @alexcrichton
@ehuss ehuss added this to the 1.22.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants