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.

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

rustdoc splits test-args wrongly #39789

Open
malbarbo opened this issue Feb 13, 2017 · 7 comments
Open

rustdoc splits test-args wrongly #39789

malbarbo opened this issue Feb 13, 2017 · 7 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@malbarbo
Copy link
Contributor

malbarbo commented Feb 13, 2017

rustdoc is splitting test-args using split_whitespace, it should use something like shlex.

After the output of rusdoc testing changes, it is not possible to run a specific test anymore. For example, consider a x.rs file:

/// ```
/// assert!(true);
/// ```
fn f() { }

With stable compiler (1.15.1), this run the test

rustdoc +stable x.rs --test --test-args --exact --test-args "f_0"

With nightly compiler (1.17.0-nightly (ba7cf7c 2017-02-11)), this does not run the test

rustdoc +nightly x.rs --test --test-args --exact --test-args "x.rs - line 1"

Note that I'm taking the test name using rustdoc +stable x.rs --test --test-args --list

It would be great if something like rustdoc +nightly x.rs --test --test-args '--exact "x.rs - line 1"' worked.

@malbarbo
Copy link
Contributor Author

cc @GuillaumeGomez

@GuillaumeGomez
Copy link
Member

As far as I can tell, it has been like this way before I made this change. However you're right, we shouldn't parse this way.

Also, please note that it's now possible to do:

rustdoc +stable x.rs --test --test-args --exact --test-args "f"

Since this PR got merged.

@GuillaumeGomez GuillaumeGomez self-assigned this Feb 13, 2017
@codyps
Copy link
Contributor

codyps commented Feb 13, 2017

I'd like to note that allowing multiple test-args and not splitting would allow a fool proof, but not too convenient way to easily cover all possible argument contents. Could be implemented with an alternate to --test-args that doesn't split (say, --test-arg) for backwards compatibility.

@Mark-Simulacrum
Copy link
Member

@GuillaumeGomez You assigned this to yourself, but I believe nothing has been done here -- it's not super clear to me what direction we want to take either; I think the two main proposals are --test-arg (probably passable multiple times) and splitting with something like shlex. We could use shlex today fairly easily, though I'm uncertain that's the best solution here. The crate doesn't look quite ideal to its handling of only UTF-8 data (taking and returning &str) when it doesn't appear strictly necessary.

@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented May 23, 2017

I didn't do anything on this because I'm not convinced by the proposed suggestion. I wanted to talk about it in a doc meeting but completely forgot. Adding needed tags.

EDIT: it seems it has already be done actually so I guess we can just close this issue.

@malbarbo
Copy link
Contributor Author

@GuillaumeGomez I do not see any change in the code. What do you mean by "it seems it has already be done actually"?

@GuillaumeGomez
Copy link
Member

Indeed, my bad. Went way too quickly when looking at the code.

@Mark-Simulacrum Mark-Simulacrum added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jun 23, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@GuillaumeGomez GuillaumeGomez removed their assignment Feb 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants