`#[cfg_attr]` doesn't work with `path` attribute

[klutzy]

$ rustc -Vv
rustc 1.1.0-nightly (e5394240a 2015-05-14) (built 2015-05-14)
binary: rustc
commit-hash: e5394240a295650b567aa406b4a0e1e3a6749a5f
commit-date: 2015-05-14
build-date: 2015-05-14
host: x86_64-unknown-linux-gnu
release: 1.1.0-nightly

$ echo 'fn i_am_b() {}' > b.rs
$ echo '#[cfg_attr(foo, path="b.rs")] mod c; fn main() {}' > a.rs
$ rustc a.rs --cfg foo
a.rs:2:5: 2:6 error: file not found for module `c`
a.rs:2 mod c;
           ^
a.rs:2:5: 2:6 help: name the file either c.rs or c/mod.rs inside the directory ""

$ echo 'fn i_am_c() {}' > c.rs
$ rustc a.rs --cfg foo
c.rs:1:1: 1:15 warning: function is never used: `i_am_c`, #[warn(dead_code)] on by default
c.rs:1 fn i_am_c() {}
       ^~~~~~~~~~~~~~
a.rs:1:17: 1:29 warning: unused attribute, #[warn(unused_attributes)] on by default
a.rs:1 #[cfg_attr(foo, path="b.rs")]
                       ^~~~~~~~~~~~

This occurs because #[cfg_attr] is processed at phase 2 (configure and expand) but #[path] is done at phase 1 (parse).

[brson]

Yeah, #[path] is kinda special since it gets used so early. I don't know offhand of any other attributes like that.

[crazymykl]

A similar issue is found with conditional including of modules.

Consider the program:

#[cfg(test)]
mod fake;

fn main() {
  println!("testing");
}

This should only fail to compile in test mode, instead we see:

<anon>:2:5: 2:9 error: file not found for module `fake`
<anon>:2 mod fake;
             ^~~~
<anon>:2:5: 2:9 help: name the file either fake.rs or fake/mod.rs inside the directory ""
playpen: application terminated with error code 101

Interactive repro here.

[eddyb]

We should totally move cfg expansion to parse-time, so that #[path] gets seen by the compiler, instead of having two hacky passes.

Also, we might want to avoid loading and parsing a module if we see #[cfg(foo)] and --cfg foo is not enabled. This would allow toggling the use of experimental syntax based on cfg flags which is easier than what we have to go through today.

[eddyb]

I didn't get to this before the beta.
@jseyfried Did you say you wanted to work on something like this?

[jseyfried]

@eddyb yeah, I was plannning on doing cfg processing after parsing during expansion, but it looks like this will require at least some cfg processing during parsing.

I like the idea of not loading or parsing an unconfigured module, but that will probably need more discussion.

cf #32846 and #32006
cc @nrc