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.

Sign up for GitHub

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

Jump to bottom

Make extract-tests.py use the same test directives as rustdoc's test extractor #11362

Closed
brson opened this issue Jan 7, 2014 · 4 comments
Closed

Make extract-tests.py use the same test directives as rustdoc's test extractor #11362

brson opened this issue Jan 7, 2014 · 4 comments
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Jan 7, 2014

Right now to rustdoc supports ignore for marking tests as broken (same as rustc) and should_fail for indicating tests that are supposed to fail. The script we use for extracting tests from the standalone docs supports xfail-test for marking broken tests, ignore and notrust for completely ignoring the code block, and doesn't support should_fail at all.

Make extract-tests.py behave the same as rustdoc.

Alternately, just process all our standalone docs through rustdoc.
@brson brson mentioned this issue Jan 7, 2014
Closed
@wting wting mentioned this issue Jan 12, 2014
Merged
@wting
Copy link
Contributor

wting commented Jan 12, 2014

When you mention should_fail, are you referring to code block directives (~~~ { .should_fail }) or function attribute (#[should_fail])?

If should_fail is found, what do you want done?

@brson
Copy link
Contributor Author

brson commented Jan 12, 2014

@wting I'd like to add { .should_fail } to the directives that extract-tests.py understands, to match #[should_fail] in unit tests and ````rust,should_fail` in rustdoc tests. Right now there are a number of tests in the docs that are disabled because they are expected to fail.

I'm not sure the best way to fix this actually because of the way these tests are run. Currently what happens is that they are extracted to a directory and then the compiletest test driver is run on them in 'run-pass' mode, which means they are all expected to pass.

Probably the simplest way to get this working would be to modify compiletest so that it understand a // should_fail (or //should-fail might be more consistent with other compiletest directives) directive and then when it runs the test it checks for a failure error code. extract-tests.py would add //should-fail to the tests it outputs.

Ultimately though I would like all the standalone documentation infrastructure to be folded into rustdoc.

@huonw
Copy link
Member

huonw commented Jan 12, 2014

Supporting should_fail is #3509, fwiw.

@wting
Copy link
Contributor

wting commented Jan 12, 2014

Alright, I've updated extract-tests.py to support { .should_fail } and output //should-fail into the fragment .rs files.

bors added a commit that referenced this issue Jan 28, 2014
@bors
auto merge of #11490 : wting/rust/wting_11362_update_extract_tests, r…
edfb546 
…=alexcrichton

Refactored the file quite a bit, I can add unit tests if desired. There's a few changes from the previous version's behavior:

- destination directory will be created if it doesn't exist
- strings and file is written as unicode

I have a few questions, but will ask them in #11362.
@bors bors closed this as completed in 9f60e7c Jan 28, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 24, 2023
@bors
Auto merge of rust-lang#11362 - y21:superfluous_impl, r=xFrednet
df68b71 
new lint: `implied_bounds_in_impls`

Closes rust-lang#10849

A new lint that looks for explicitly specified bounds that are already implied by other bounds in `impl Trait` return position types.
One example, as shown in the linked example, would be
```rs
fn foo<T>(x: T) -> impl Deref<Target = T> + DerefMut<Target = T> {
    Box::new(x)
}
```
`DerefMut<Target = T>` requires  `Deref<Target = T>` to be wellformed, so specifying `Deref` there is unnecessary.

This currently "ignores" (i.e., does not lint at all) transitive supertrait bounds (e.g. `trait A {} trait B: A {} trait C: B {}`, then having an `impl A + C` type), because that seems a bit more difficult and I think this isn't technically a blocker. It leads to FNs, but shouldn't bring any FPs

changelog: new lint [`implied_bounds_in_impls`]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@brson @wting @huonw