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

file!() macro return absolute path in doc-test compile #46372

Closed
la10736 opened this issue Nov 29, 2017 · 3 comments · Fixed by rust-lang/cargo#12221
Closed

file!() macro return absolute path in doc-test compile #46372

la10736 opened this issue Nov 29, 2017 · 3 comments · Fixed by rust-lang/cargo#12221
Labels
A-doctests Area: Documentation tests, run by rustdoc A-parser Area: The parsing of Rust source code to an AST C-bug Category: This is a bug. T-libs-api Relevant to the library API team, 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

@la10736
Copy link
Contributor

la10736 commented Nov 29, 2017

This a minimal example. Standard compilation resolve file!() macro as relative project path but doc-test compilation emit follow error:

error: couldn't read "/home/mdamico/temp/doc_test_file_bug/src/..//home/mdamico/temp/doc_test_file_bug/src/lib.rs.bis.rs": No such file or directory (os error 2)
 --> /home/mdamico/temp/doc_test_file_bug/src/lib.rs:1:1
  |
1 | include!(concat!("../", file!(), ".bis.rs"));
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This behavior involve just include!() macro because when used in function or assignment works like as expected

///
/// ```
/// assert_eq!("src/lib.rs", file!())
/// ```

/// ```
/// assert_eq!("src/lib.rs", doc_test_file_bug::path())
/// ```
pub fn path() -> &'static str {
    file!()
}

///
/// ```
/// assert_eq!("src/lib.rs", doc_test_file_bug::f)
/// ```
pub static f: &'static str = file!();
   Doc-tests doc_test_file_bug

running 3 tests
test src/lib.rs - path (line 6) ... ok
test src/lib.rs - f (line 14) ... ok
test src/lib.rs - path (line 2) ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Now I should disable doc-test to use file!() for including some auto-generated code.

@kennytm kennytm added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools-rustdoc T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. A-parser Area: The parsing of Rust source code to an AST and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools-rustdoc T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 29, 2017
@la10736
Copy link
Contributor Author

la10736 commented Jan 12, 2018

Sadly this bug is also present when we include an external crate that use include!() and file!() combo.

@XAMPPRocky XAMPPRocky added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Feb 19, 2018
@steveklabnik
Copy link
Member

Triage: this still fails to compile.

@jyn514 jyn514 added the A-doctests Area: Documentation tests, run by rustdoc label Nov 4, 2020
@Swatinem
Copy link
Contributor

Out of curiousity, I tried the usecase with cargo +nightly test -Z doctest-in-workspace (See rust-lang/cargo#9427), as I want to eventually turn that on by default soon, and the works fine with that flag. So assuming I can make that the default behavior after the next release, this should eventually work by 1.72, lets see about that timeline :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-doctests Area: Documentation tests, run by rustdoc A-parser Area: The parsing of Rust source code to an AST C-bug Category: This is a bug. T-libs-api Relevant to the library API team, 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

Successfully merging a pull request may close this issue.

6 participants