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

test for doctest path problem #8531, and solution #12710

Closed
wants to merge 5 commits into from
Closed

test for doctest path problem #8531, and solution #12710

wants to merge 5 commits into from

Conversation

tompscanlan
Copy link
Contributor

What does this PR try to resolve?

Fixes issue #8531 , wherein we have doctests that fail with a shared library error.

The issue seems painful enough that folks are changing their code to avoid this bug. We need a solution.

How should we test and review this PR?

I added a tentative test that reproduces the problem, and reusing #10469, show that solution works.
The repair in question is small. Toggle it off and the test fails with shared library problems.

@rustbot
Copy link
Collaborator

rustbot commented Sep 20, 2023

r? @weihanglo

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added A-build-execution Area: anything dealing with executing the compiler S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 20, 2023
tests/testsuite/test.rs Outdated Show resolved Hide resolved
sgrif and others added 3 commits September 19, 2023 22:33
Fixes #8531.

This issue was introduced by 3fd2814.
Prior to that commit, the `rustdoc_process` function took other branch
of the if statement being modified by this commit. The flag was
previously called `is_host`, and `rustdoc` was run reporting `false`. In
that commit, the flag was changed to `is_rustc_tool`, and rustdoc began
reporting `true`, which resulted in the native directories added by
build scripts no longer being appended to LD_LIBRARY_PATH when running
doctests.

This commit changes the behavior so that we are always appending the
same set of paths, and the only variance is if we are cross compiling or
not. An alternative would be to change rustdoc to always pass
`kind: CompileKind::Host, is_rustc_tool: false`, but as rustdoc is in
fact a rustc tool, that feels wrong. The commit which introduced the bug
did not include context on why the flag was changed to `is_rustc_tool`,
so I don't have a sense for if we should just change that flag to mean
something else.

While the test suite previously had an explicit test for the
library path behavior of `cargo run`, it did not test this for various
test forms. This commit modifies the test to ensure the behavior is
consistent across `run`, normal tests, and doctests.
* add test reproducing #8531
* re-use solution from #10469
* solution fixes test
@tompscanlan
Copy link
Contributor Author

I added a test that reproduces the error initially seen in the initial tensorflow issue. I'd like to reduce that to a few files that reproduce the error so I can include it into a unit test. I'm not having luck, so if anyone wants to take a crack at it, let me know. I can get you details.

I then pulled in @sgrif change from #10469 on top, and agree that the change is making the reproduced error go away. Thanks @sgrif!

Additionally, I verified that the following can work as a temporary work around if you've got the shared library installed in your system. /usr/loca/lib is where the library was installed in my system.

LD_LIBRARY_PATH=/usr/local/lib  cargo test --doc

I feel like adding a build.rs should also be another path to do accomplishing the same thing, but haven't made it work yet.

I'm going to go read #3366 and think on this a little longer. Next goal is slimming this test down. Anything else you want to see to close this out?

@tompscanlan
Copy link
Contributor Author

I'm spinning my wheels on making a tiny test that replicates the problem. I removed the test that hits the network. We lose the exact error replication, but the test that remains ensures we have good results assuming you get libs in the right place,.

@epage or @weihanglo , what else should I cover to get this closed?

@djc
Copy link
Contributor

djc commented Feb 1, 2024

We're running into this for rustls. Seems like a strange bug (potentially a regression?) with potentially a straightforward fix? Cargo team, any hints on moving this forward? I could invest some time to help this along if necessary.

Copy link
Member

@weihanglo weihanglo left a comment

Choose a reason for hiding this comment

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

Sorry for the delay. While I think a proper solution would rustdoc delegate doctests runnning to cargo (which should be tracked in rust-lang/testing-devex-team#5), we should try moving this forwards, or at least have a conclusion what to do next. Will put this in the agenda of the triage meeting.

src/cargo/core/compiler/compilation.rs Outdated Show resolved Hide resolved
src/cargo/core/compiler/compilation.rs Show resolved Hide resolved
@tompscanlan tompscanlan closed this by deleting the head repository Feb 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-build-execution Area: anything dealing with executing the compiler S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants