Description
From #54824 (comment):
[ ] impl-everywhere.rs:// @!has foo/fn.foo.html '//section[@id="main"]//pre' "x: &'x impl Foo"
This test looks strange. The generated documentation looks like this (wrapped in pre):
pub fn foo<'x>( x: &'x impl Foo ) -> &'x impl Foo
so it seems like the backslash in the test is taken literally which means that it doesn't match. Is that on purpose? @GuillaumeGomez it seems like you created the test, so perhaps you can enlighten me?
Edit: To be clear, removing the backslash from the test causes the test to fail.
My understanding is that test is trying to assert that fn.foo.html
doesn't contain the phrase x: &' impl Foo
, but because it is erroneously escaping a quote it fails to make that assertion. Furthermore, the generated fn.foo.html
file actually does contain the text being checked for, so there is a bug in rustdoc as well.
Activity
Munksgaard commentedon Oct 19, 2018
This issue should be assigned to @GuillaumeGomez, as per his request in #54824 (comment)
@!has
and@!matches
#54824liketechnik commentedon Oct 24, 2020
@rustbot claim
liketechnik commentedon Oct 25, 2020
I've made the following observations:
rustdoc
for the test is the same as the output with the initial implementation used with the test (e67bba8) and also seems to match with the initial goal of the implementation in Fix missing impl trait display as ret type #53541. (I don't think the actual output ofrustdoc
is necessary here, but can provide that if needed).rustdoc
though, due to my unfamiliarity withrustdoc
s code.My interpretation is that there is no bug in
rustdoc
(since the output stayed the same), but the test simply never validated the output correctly, because@!has
) of animpl Type
in parameters or return values, while the original goal of the implementation (see Fix missing impl trait display as ret type #53541) was to add support forimpl Type
in parameters and return values. Example:rust/src/test/rustdoc/impl-everywhere.rs
Lines 11 to 13 in 430feb2
pub fn foo<'x>(x: &'x impl Foo) -> &'x impl Foo
as documentation{
after the return type, which is not generated byrustdoc
. This makes the checks work, because now the 'expected' (see point 1) mismatch occurs.If my observations are correct, I would go forward by opening a pr fixing the issues listed above for the test (e. g. making the test fail for possibly incorrect output by
rustdoc
in the future).jyn514 commentedon Nov 4, 2020
@GuillaumeGomez can you confirm whether the summary above is correct?
GuillaumeGomez commentedon Nov 4, 2020
Yes, it seems to be correct. Thanks for the summary @liketechnik ! Please feel free to open the PR. :)
Rollup merge of rust-lang#78727 - liketechnik:issue-55201, r=Guillaum…
Rollup merge of rust-lang#78727 - liketechnik:issue-55201, r=Guillaum…
Rollup merge of rust-lang#78727 - liketechnik:issue-55201, r=Guillaum…
Rollup merge of rust-lang#78727 - liketechnik:issue-55201, r=Guillaum…