Skip to content

Compiler must show real line in failed test #29253

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
KalitaAlexey opened this issue Oct 23, 2015 · 13 comments
Closed

Compiler must show real line in failed test #29253

KalitaAlexey opened this issue Oct 23, 2015 · 13 comments
Labels
T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@KalitaAlexey
Copy link
Contributor

Currently if some test fails then compiler shows error with relative position <anon>:21:5. This is very uncomfortable

@apasel422
Copy link
Contributor

Could you provide some more information or some example code / steps to reproduce this?

@KalitaAlexey
Copy link
Contributor Author

Any test, any syntax error or assert shows positition relative to test begin

@apasel422
Copy link
Contributor

Are you talking about the tests that are run by make check, #[test] functions in user code run through e.g. cargo test, or something else?

@KalitaAlexey
Copy link
Contributor Author

I mean documentation test running through cargo test

@apasel422
Copy link
Contributor

OK, so to elaborate, the issue here is that doc test failures don't include the name of the file that contains the doc test. This is a result of how rustdoc works, which is by passing the source code of the test, as extracted from the comment in the file, to rustc via stdin. We can probably add an unstable command-line argument to rustc that allows a file name to be specified in such scenarios and amend rustdoc to use it.

@KalitaAlexey
Copy link
Contributor Author

Do something, please.

@apasel422
Copy link
Contributor

I'm investigating implementing this now.

@apasel422
Copy link
Contributor

This doesn't actually need a command-line option added to rustc, as rustdoc calls driver::compile_input directly, making this change simpler.

@steveklabnik steveklabnik added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Oct 26, 2015
@steveklabnik
Copy link
Member

Do something, please.

Please try to recognize that this is an open source project, and many people are working in their spare time. Specifically, as far as I know, @apasel422 is not paid to work on Rust. While we want Rust to be great for everyone, the reality is that there are thousands of open bugs, and so some of them will take time to address.

@KalitaAlexey
Copy link
Contributor Author

@steveklabnik Do you want me to do that? Could you aim me to this? Should I examine cargo sources?

@apasel422
Copy link
Contributor

@KalitaAlexey If you're interested in implementing this yourself (I don't know when I'll be able to complete it), the general idea would be augmenting rustc::session::config::Input::String with an Option<PathBuf> or perhaps Option<String> that carries a "secondary" filename that will be used in rustdoc.

@michaelwoerister michaelwoerister added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. and removed A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) labels Nov 4, 2015
@mitaa
Copy link
Contributor

mitaa commented Feb 19, 2016

Thanks @apasel422, I've implemented the filename part here, but it turns out that solving the issue with line numbers being relative to the start of the codeblock instead of to the start of the file is kind of infeasible to solve (which is AIUI the main request from @KalitaAlexey).

The current <anon> is I think preferable to showing the correct filename with wrong line numbers.

bors added a commit that referenced this issue Mar 14, 2016
Allow custom filenames for anonymous inputs

This came out of #29253 but doesn't fix it.

I thought it might be worth merging on its own nonetheless.
@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@GuillaumeGomez
Copy link
Member

I think we can close it? Just reopen it if you feel something is missing.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. 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

6 participants