Skip to content

make check creates files example{1,2,3}.dot #13965

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

Closed
lilyball opened this issue May 6, 2014 · 2 comments · Fixed by #13976
Closed

make check creates files example{1,2,3}.dot #13965

lilyball opened this issue May 6, 2014 · 2 comments · Fixed by #13976

Comments

@lilyball
Copy link
Contributor

lilyball commented May 6, 2014

It looks like the doc tests for libgraphviz create files example{1,2,3}.dot, which end up being left behind in the cwd after running make check.

I'm not sure what the correct solution here is. The doc tests could explicitly try to write to /tmp, but it may make more sense for rustdoc's test runner to use a temporary directory as the cwd so the individual tests don't have to worry about this.

@pnkfelix
Copy link
Member

pnkfelix commented May 6, 2014

cc me

@pnkfelix
Copy link
Member

pnkfelix commented May 6, 2014

a simpler short-term solution could be to avoid generating the files in the first place.

  • Easiest way to do that: Add either ignore or preferably no_run to the code blocks.
  • Slightly harder (but better for testing): refactor the code so that the graphviz testing parts are parameterized over their Writer. Add a hidden code block that runs those with an in-memory writer. Then add a shown but ignore'd code block that just contains a very short main that calls out to the functions from the earlier block.

pnkfelix added a commit to pnkfelix/rust that referenced this issue May 6, 2014
…oc runs.

Fix rust-lang#13965.

There is a dance here between the `main` that actually runs versus the
`main` that is printed in the output documentation.  We don't run the
latter `main`, but we do at least compile (and thus type-check) it.
It is still the responsibility of the documenter to ensure that the
signatures of `fn render` are kept in sync across the blocks.
bors added a commit that referenced this issue May 8, 2014
Fix #13965.

This commit adopts the second strategy I outlined in #13965, where the bulk of the code is still "smoke tested" (in the sense that rustdoc attempts to run it, sending all of the generated output into a locally allocated `MemWriter`).  The part of the code that is ignored (but included in the presentation) is isolated to a three-line `main` function that invokes the core rendering routine.

In the generated rustdoc output, this leads to a small break between the two code blocks, but I do not think this is a large issue.
michaelwoerister pushed a commit to michaelwoerister/rust that referenced this issue Jun 5, 2014
…oc runs.

Fix rust-lang#13965.

There is a dance here between the `main` that actually runs versus the
`main` that is printed in the output documentation.  We don't run the
latter `main`, but we do at least compile (and thus type-check) it.
It is still the responsibility of the documenter to ensure that the
signatures of `fn render` are kept in sync across the blocks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants