-
Notifications
You must be signed in to change notification settings - Fork 543
add new section on the rustdoc
test suite
#2295
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this. I have a couple of comments!
Also CC @GuillaumeGomez @notriddle |
@fmease I think I've managed to address all your comments in a way I'm satisfied with, does this look good? |
Merging since rustdoc maintainers approved, can always be improved in follow-ups. |
(rust-lang/team#1704 will allow rustdoc maintainers to have write access to this repo, since it makes no sense if the rustdoc experts can't merge rustdoc doc changes.) |
Noo, my review wasn't done (this still has several smallish issues) :/ I'll create a follow-up PR |
Oh sorry :( |
|
||
The `rustdoc` test suite is specifically used to test the HTML output of rustdoc. | ||
|
||
This is achived by means of `htmldocck.py`, a custom checker script that leverages [XPath]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is achived by means of `htmldocck.py`, a custom checker script that leverages [XPath]. | |
This is achieved by means of `htmldocck.py`, a custom checker script that leverages [XPath]. |
|
||
Usage: `//@ matches PATH XPATH PATTERN` | ||
|
||
Checks that the text of each element selected by `XPATH` in `PATH` matches the python-flavored regex `PATTERN`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checks that the text of each element selected by `XPATH` in `PATH` matches the python-flavored regex `PATTERN`. | |
Checks that the text of each element selected by `XPATH` in `PATH` matches the Python-flavored regex `PATTERN`. |
|
||
In the first form, `has` checks that a given file exists. | ||
|
||
In the second form, `has` is an alias for `matches`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the second form, `has` is an alias for `matches`, | |
In the second form, `has` is the same as `matches`, |
If it's not the same it's not an alias :)
|
||
Usage: `//@ has-dir PATH` | ||
|
||
Checks for the existance of directory `PATH`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checks for the existance of directory `PATH`. | |
Checks for the existence of directory `PATH`. |
[^1]: Whitespace normalization means that all spans of consecutive whitespace are replaced with a single space. The files themselves are also whitespace-normalized. | ||
|
||
## Limitations | ||
`htmldocck.py` uses the xpath implementation from the standard library. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`htmldocck.py` uses the xpath implementation from the standard library. | |
`htmldocck.py` uses the XPath implementation from the standard library. |
`ENTRIES` is a python list of strings inside a quoted string, | ||
as if it were to be parsed by `eval`. | ||
(note that the list is actually parsed by `shlex.split`, | ||
so it cannot contain arbitrary python expressions). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`ENTRIES` is a python list of strings inside a quoted string, | |
as if it were to be parsed by `eval`. | |
(note that the list is actually parsed by `shlex.split`, | |
so it cannot contain arbitrary python expressions). | |
`ENTRIES` is a Python list of strings inside a quoted string, | |
as if it were to be parsed by `eval`. | |
(note that the list is actually parsed by `shlex.split`, | |
so it cannot contain arbitrary Python expressions). |
|
||
### `hasraw` | ||
|
||
Usage: `//@ hasraw PATH PATTERN` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage: `//@ hasraw PATH PATTERN` | |
Usage: `//@ hasraw PATH XPATH PATTERN` |
+ extending prose description
|
||
### `matchesraw` | ||
|
||
Usage: `//@ matchesraw PATH PATTERN` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage: `//@ matchesraw PATH PATTERN` | |
Usage: `//@ matchesraw PATH XPATH PATTERN` |
+ extending prose description
|
||
Usage: `//@ hasraw PATH PATTERN` | ||
|
||
Same as `matchesraw`, except `PATTERN` is a whitespace-normalized[^1] string instead of a regex. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only mentions in the footnote that file's contents are also whitespace normalized. However, that's arguably more important (in 99% cases the PATTERN the test author writes is normalized already). This should be the other way around.
In the first form, `has` checks that a given file exists. | ||
|
||
In the second form, `has` is an alias for `matches`, | ||
except `PATTERN` is a whitespace-normalized[^1] string instead of a regex. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
Also this should've been squashed ^^' (the last 7 commits were just fixups and thus should't've become part of the final history) |
I can address some of the stuff you mentioned unless you already have changes locally, I'll also add a bit more on how this is wired up between bootstrap <-> rustdoc test suites. (Sorry) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://rustc-dev-guide.rust-lang.org/rustdoc-internals.html#dotting-is-and-crossing-ts already mentions htmldocck albeit more briefly. Furthermore it mentions useful compiletest directives like //@ build-aux-docs
.
We should remove this section and import some of the additional pieces of information into this document. We should also mention compiletest directive //@ doc-flags
.
I already have my editor open and will open a PR in <30 minutes I guess. Feel free to add extra information after that :) |
`rustdoc` tests also support most | ||
[compiletest directives](../tests/directives.html). | ||
|
||
All `PATH`s in directives are relative to the the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I'm confusing myself, if you say the path is relative to build/$TARGET/test/rustdoc/$CRATE_NAME
I would think a path like foo/fn.bar.html
would expand to build/$TARGET/test/rustdoc/foo/foo/fn.bar.html
assuming the crate name is foo
(notice the double foo/
).
I would describe it as relative to build/$TARGET/test/rustdoc/
in which case this sentence merely describes an implementation detail of compiletest which the test writer shouldn't need to worry about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is tests/rustdoc
supposed to support revisions? I'm assuming the answer is "no", but I don't see it being explicitly rejected.
(Asking because revision is part of the output dir name mangling)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're currently rejected by compiletest (via an assert) since htmldocck.py has no notion of that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, https://github.com/rust-lang/rust/blob/4e2b096ed6c8a1400624a54f6c4fd0c0ce48a579/src/tools/compiletest/src/runtest/rustdoc.rs#L7. I was looking at another place where I did the rejection 💀 I should fix that as part of the compiletest directive handling rework.
Currently this stuff is only documented in a comment at the start of
htmldocck.py
, and that commend is very outdated and often missing important details, like the fact thathas
andmatches
are accept different kinds of patterns.