!include'd source has all debug/error line numbers attributed to !include statement

[vvuk]

as in https://github.com/servo/ipc-channel/blob/master/src/platform/mod.rs#L18

Tested on nightly-x86_64-pc-windows-gnu rustc 1.13.0-nightly (497d67d 2016-09-01), and with mingw64 gdb.

[vvuk]

Note: if I build with "-Z debug-macros" line numbers get properly attributed to the included source; not sure if this is intentional behaviour in this case?

[vvuk]

Or.. not completely. With -Z debug-macros:

vladimir@grizzly[2334]$ cargo build
   Compiling ipc-channel v0.5.1 (file:///C:/proj/r/ipc-channel)
error[E0308]: mismatched types
  --> src\platform/mod.rs:18:5
   |
18 |     include!("windows/mod.rs");
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected &str, found struct `std::string::String`
   |
   = note: expected type `&str`
   = note:    found type `std::string::String`
   = note: this error originates in a macro from the standard library

error: aborting due to previous error

error: Could not compile `ipc-channel`.

[vvuk]

For the record, the error line was:

                return Err(WinError::last(format!("WaitForMultipleObjectsEx returned {}", index)));

with last() wanting a &str. If I changed this to cause another error, it was reported to the right line properly.

[raphaelcohn]

I'm not sure if this is related, but I've noticed include! has a different path when invoked from inside a macro.

For example, if I have mod linux_like_syscall, and linux_like_syscall/mod.rs, then if mod.rs does include!("code.rs")';, code.rs is found in linux_like_syscall/ and all's well. If I have the include! inside a macro, eg conditionally compiling using cfg_if!, then code.rs is searched for in ..

[vadimcn]

Note: if I build with "-Z debug-macros" line numbers get properly attributed to the included source; not sure if this is intentional behaviour in this case?

Yes, this is intentional: #35238. Most of the time you want to step over macros. But if not, that's what -Z debug-macros is was intended for.

[vvuk]

include! seems like it should be special though. Is it even implementable via macro_rules!?

[vadimcn]

The debug info emission code treats all macros uniformly, whether they are MBEs or procedural. Singling out include! would be... hacky.
Regarding your case, is there a reason you've avoided the usual "conditionally compiled module" approach?

[vvuk]

Hacky, but perhaps a lot less unexpected. No reason; legacy code that did it this way. I may do a PR to change it.

[comex]

Just ran into this. It's not possible to avoid include! when using code generated at build time, like with syntex: can't use a path attribute on a mod declaration because of the concat!(env("OUT_DIR") bit. (I tried to work around this by include!-ing a generated rs file that just consists of a mod decl, but somewhat counterintuitively to me, that doesn't change anything: everything in the module has debug info pointing to the include!.)

[jdm]

Servo is in a similar bind to the previous comment - we generate a lot of code in the out directory, and there's no way to reference it without using env!("OUT_DIR").