-
Notifications
You must be signed in to change notification settings - Fork 13.4k
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
Comments
cc me |
a simpler short-term solution could be to avoid generating the files in the first place.
|
This was referenced May 6, 2014
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.
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Apr 20, 2024
…, r=Veykril Wrap/Unwrap cfg_attr https://github.com/rust-lang/rust-analyzer/assets/11785959/f5f1bb71-22e7-438b-9a22-65ebab1b362d https://github.com/rust-lang/rust-analyzer/assets/11785959/36933a4e-0000-455a-abe3-af774cd854d0 ## TODO - [x] Add Tests - [x] Wrap derive elements Closes rust-lang#13965
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Apr 20, 2024
…, r=Veykril Wrap/Unwrap cfg_attr https://github.com/rust-lang/rust-analyzer/assets/11785959/f5f1bb71-22e7-438b-9a22-65ebab1b362d https://github.com/rust-lang/rust-analyzer/assets/11785959/36933a4e-0000-455a-abe3-af774cd854d0 ## TODO - [x] Add Tests - [x] Wrap derive elements Closes rust-lang#13965
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: