Possible regression at nightly-2016-06-15 for include_str! macro

[kbknapp]

I have an example which internally uses include_str! to pull in the contents of a file in the same directory. This example fails to buid on all nightlies after 2016-06-14 (ab0b87458), yet passes on ab0b87458 and all prior (including stable).

The error message I get is:

error: couldn't read 17_yaml.yml: No such file or directory (os error 2)
 --> <clap macros>:2:44
  |>
2 |> & :: clap :: YamlLoader :: load_from_str ( include_str ! ( $ yml ) ) . expect
  |>                                            ^^^^^^^^^^^^^^^^^^^^^^^
examples/17_yaml.rs:32:15: 32:40: note: in this expansion of load_yaml! (defined in <clap macros>)

error: aborting due to previous error
error: Could not compile `clap`.

To learn more, run the command again with --verbose.

The only commit that seems even somewhat related is 4259fba7e6?

[TimNN]

I believe this may have been caused by #34187.

Edit: Apparently not, testing with that commit reverted did not fix the problem.

[TimNN]

I can confirm that reverting 4259fba fixes the problem.

cc @jseyfried

The following code reproduces the issue:

bar.rs:

#![crate_type = "lib"]

#[macro_use]
mod foo;

load_data!("data.txt");

data.txt: Any file, contents don't matter.

foo/mod.rs:

macro_rules! load_data { ($file:expr) => {
    static DATA: &'static str = include_str!($file);
}}

[jseyfried]

@TimNN Thanks for the cc and the minimal example! This was caused by #33749.

I think this is a bug-fix -- include_str! is now searching in the directory foo, where it was written, rather than ., where it ended up getting expanded. This allows macro authors to use include_str! in macro definitions without worrying about where users will use the macros.

That being said, if this is causing significant breakage in practice, we should fix it (not that hard) or do a warning cycle (also not that hard). Maybe we could do a crater run to determine breakage?

cc @nrc

[TimNN]

@jseyfried: Will the new behaviour ever work with macros imported from extern crates? I imagine not, since the extern crate's sources will not necessarily be available.

[jseyfried]

@TimNN Good point, macros from extern crates that use include_str wouldn't work.

Perhaps we should just keep the old behaviour -- the new behaviour may not be enough of an improvement to justify potential breakage or a warning cycle.

[sfackler]

A mild ergonomic improvement seems far from what I'd want to see to justify breaking significant amounts of code in the real world, regardless of the existence of a warning period.

[jseyfried]

@stacker agreed -- we would only consider the change if crater found virtually no breakage.

[Ericson2314]

I think this is the correct semantics, anywhere to file an issue for macros 2.0?

[Ericson2314]

For the extern crate perhaps something like scheme's let-syntax could be used to evaluate the macro outside the macro body, and the substitute it's evaluation via an identifier inside?

[jseyfried]

Maybe comment on one if @nrc''s RFCs -- probably RFC 1584.

[jseyfried]

Hmm, I'll have to look into let-syntax a bit more to understand that.
Another idea for extern crates could be to have the search path be based on the source location of the file name itself, not the include! macro invocation. This would alow someone to define my_include!().