Regression: source code location is bad in nightly (doctests)

[xmppftw]

Code

I tried this code in xso/src/from_xml_doc.md :

Example without codec

# // extern crate alloc;
# use xso::FromXml;
#[derive(FromXml, Debug, PartialEq)]
#[xml(namespace = "urn:example", name = "foo")]
struct Foo {
    #[xml(text)]
    a: String,
};

let foo: Foo = xso::from_bytes(b"<foo xmlns='urn:example'>hello</foo>").unwrap();
assert_eq!(foo, Foo {
    a: "hello".to_string(),
});

(i commented extern crate alloc but in start it was just not there)

I expected to see this happen: reporting error produced in xso/src/from_xml_doc.md line ~600

Instead, this happened: reported error produced in xso/src/lib.rs line ~600 (does not exist)

failures:

---- xso/src/lib.rs - FromXml (line 648) stdout ----
error[E0433]: failed to resolve: could not find `alloc` in the list of imported crates
 --> xso/src/lib.rs:652:10
  |
7 | #[derive(FromXml, Debug, PartialEq)]
  |          ^^^^^^^ could not find `alloc` in the list of imported crates
  |
  = note: this error originates in the derive macro `FromXml` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this module
  |
3 + use std::string;
  |

error[E0433]: failed to resolve: could not find `alloc` in the list of imported crates
 --> xso/src/lib.rs:652:10
  |
7 | #[derive(FromXml, Debug, PartialEq)]
  |          ^^^^^^^ could not find `alloc` in the list of imported crates
  |
  = note: this error originates in the derive macro `FromXml` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this struct
  |
3 + use std::string::String;
  |

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0433`.
Couldn't compile the test.

failures:
    xso/src/lib.rs - FromXml (line 648)

test result: FAILED. 9 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.39s

error: doctest failed, to rerun pass `--doc`

Version it worked on

Works on stable:

---- xso/src/from_xml_doc.md - FromXml (line 590) stdout ----
error[E0433]: failed to resolve: could not find `alloc` in the list of imported crates
 --> xso/src/from_xml_doc.md:594:10
  |
7 | #[derive(FromXml, Debug, PartialEq)]
  |          ^^^^^^^ could not find `alloc` in the list of imported crates
  |
  = note: this error originates in the derive macro `FromXml` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this module
  |
3 + use std::string;
  |

error[E0433]: failed to resolve: could not find `alloc` in the list of imported crates
 --> xso/src/from_xml_doc.md:594:10
  |
7 | #[derive(FromXml, Debug, PartialEq)]
  |          ^^^^^^^ could not find `alloc` in the list of imported crates
  |
  = note: this error originates in the derive macro `FromXml` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this struct
  |
3 + use std::string::String;
  |

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0433`.
Couldn't compile the test.

failures:
    xso/src/from_xml_doc.md - FromXml (line 590)

test result: FAILED. 9 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.04s

error: doctest failed, to rerun pass `--doc`

Version with regression

rustc --version --verbose:

rustc 1.85.0-nightly (4ba4ac612 2024-12-18)
binary: rustc
commit-hash: 4ba4ac612d36e3409e8e1e31e12acc028808f85f
commit-date: 2024-12-18
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.6

[apiraino]

@xmppftw can you provide a way for us to reproduce this issue (code and command line instructions) so we can more easily bisect where this was introduced? Thanks!

[xmppftw]

I tried make small repro case but failed very bad (did not trigger same bug). Best i have is xso repo. I made new branch for this:

git clone https://gitlab.com/xmppftw/xmpp-rs.git
cd xmpp-rs/xso
git checkout repro-rustdoc 

From there (commit e8ed28feb2962344cffc1a95fee3bf8a103f8b79):

• cargo +nightly test --all-features display broken file source
• cargo +stable test --all-features display good file source

[apiraino]

@xmppftw thanks for the git repository. I've tried your instructions and in both cases (stable and nightly) the error message is:

error: Both tls-native and tls-rust features can't be enabled at the same time.
  --> tokio-xmpp/src/lib.rs:38:1
   |
38 | compile_error!("Both tls-native and tls-rust features can't be enabled at the same time.");
   | 

which doesn't match the output in your report. Am I missing anything?

[xmppftw]

So sorry for ocnfusion. It's in xso crate and you cannot compile all workspace with all-features... i updated previous comment for repro instruction (just go in xso child folder)

I have new repro looks like same bug on same repo:

• git fetch origin
• git checkout repro-rustdoc2
• cd parsers

Nightly cargo doc --open produce warning from src/consistent_color.rs but say it's from src/lib.rs :

warning: unresolved link to `Rgb::from_resource`
 --> parsers/src/lib.rs:278:1
  |
5 | | //! element parsed correctly, `Err(error::Error)` otherwise.
  | |______________________________________________________________________________^
...
27| / /// XEP-0392: Consistent Color Generation
  |
  = note: the link appears in this line:

          - MUC user nicknames with [`Rgb::from_resource`]
                                     ^^^^^^^^^^^^^^^^^^^^
  = note: no item named `Rgb` in scope
  = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default

warning: unresolved link to `Rgb::from_barejid`
 --> parsers/src/lib.rs:278:1
  |
5 | | //! element parsed correctly, `Err(error::Error)` otherwise.
  | |______________________________________________________________________________^
...
27| / /// XEP-0392: Consistent Color Generation
  |
  = note: the link appears in this line:

          - Roster contacts and non-anonymous MUC members with [`Rgb::from_barejid`]
                                                                ^^^^^^^^^^^^^^^^^^^
  = note: no item named `Rgb` in scope

warning: `xmpp-parsers` (lib doc) generated 2 warnings

But in fact in stable same thing is produced so it looks like it's not same bug:

warning: unresolved link to `Rgb::from_resource`
 --> parsers/src/lib.rs:278:1
  |
5 | | //! element parsed correctly, `Err(error::Error)` otherwise.
  | |______________________________________________________________________________^
...
27| / /// XEP-0392: Consistent Color Generation
  |
  = note: the link appears in this line:

          - MUC user nicknames with [`Rgb::from_resource`]
                                     ^^^^^^^^^^^^^^^^^^^^
  = note: no item named `Rgb` in scope
  = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default

warning: unresolved link to `Rgb::from_barejid`
 --> parsers/src/lib.rs:278:1
  |
5 | | //! element parsed correctly, `Err(error::Error)` otherwise.
  | |______________________________________________________________________________^
...
27| / /// XEP-0392: Consistent Color Generation
  |
  = note: the link appears in this line:

          - Roster contacts and non-anonymous MUC members with [`Rgb::from_barejid`]
                                                                ^^^^^^^^^^^^^^^^^^^
  = note: no item named `Rgb` in scope

warning: `xmpp-parsers` (lib doc) generated 2 warnings

[apiraino]

I've tried bisecting without a reduced sample of the report.

searched nightlies: from nightly-2024-10-01 to nightly-2024-12-22
regressed nightly: nightly-2024-11-01
searched commit range: 759e07f...a0d98ff
regressed commit: 4add5e4

The bisection point to the rollup merge 4add5e4, namely #132210 as the point where this behaviour started.

cc @notriddle @GuillaumeGomez

A minimal reduction would still be welcome, though

@rustbot label +E-needs-mcve -S-needs-repro

[notriddle]

I don't think we can easily fix this. It's caused by a single span being used for two purposes:

• Error reporting
• Relative path resolution from the include! family of macros

Changing the relative path resolution was a breaking change, which is why 132210 exists. Changing the error reporting without changing the relative path resolution would require threading a second span through the compiler, which would add a lot of overhead and complexity for a pretty narrow corner case.