Module path attribute override with nested macros doesnt work

[Veetaha]

I tried this code:

Repository with the reproduction

I expected to see this happen:

The code should compile without errors, because this feature was advertised in Rust 1.54 announcement and in #83366.

Instead, this happened:

Compile error file not found for module generated was issued

More info in README.md of the reproduction repo

Meta

rustc --version --verbose:

rustc 1.54.0 (a178d0322 2021-07-26)
binary: rustc
commit-hash: a178d0322ce20e33eac124758e837cbd80a6f633
commit-date: 2021-07-26
host: x86_64-unknown-linux-gnu
release: 1.54.0
LLVM version: 12.0.1

cc @jyn514

[ehuss]

I can confirm this doesn't work, and is a bit unfortunate it slipped through (I admit I didn't test it).

From what I can tell, the extended attr=expr expansion happens during lowering to HIR (no, I don't know how that works), but #[path] is needed during expansion before that happens. The check here silently ignores the attribute because the value is not a string (it is a macro expression).

I don't think there is any true support for eager expansion, so I don't think there is any existing support for something like this. At a bare minimum, the #[path] attribute should generate an error if the value is not a string literal.

I think we should maybe update the release post, since it is misleading.

[danobi]

@ehuss do you think adding support for this eager expansion is feasible / welcome? I'd be interested in hacking on it if it's not terribly difficult. I also really want this feature for another project I maintain.

[ehuss]

Unfortunately I think it might be difficult to support. #[path] would likely need special handling because it is needed during expansion. I am not on the compiler or language teams, so I'm not the one to say definitively.

[Mark-Simulacrum]

cc @petrochenkov @jyn514 -- I would have expected this to work based on discussions when landing this feature, so I'm a little surprised that it doesn't.

[petrochenkov]

@Mark-Simulacrum

I would have expected this to work based on discussions when landing this feature, so I'm a little surprised that it doesn't.

Internally "mod m; -> mod m { /* contents */ }" effectively works as "#[include_it] mod m; -> mod m { /* contents */ }", i.e. it's an expansion of the primary item m, which is performed before any nested expansions (including expansions inside attributes).

At a bare minimum, the #[path] attribute should generate an error if the value is not a string literal.

+1

[N3xed]

Note: It doesn't work at all, even if the macros aren't nested. For example #[path = concat!("file.rs")] doesn't work either.

There is also the issue #48250 which is pretty much the same as this. Also the RELEASES.md should be changed to reflect that this doesn't work, it currently states that it does:

You can also use this to include auto-generated modules:

#[path = concat!(env!("OUT_DIR"), "/generated.rs")]
mod generated;

[ehuss]

Posted #88057 to update the RELEASES, thanks for catching that!

[ehuss]

Posted #88680 to add errors when attempting to use macros with #[path].

[malaire]

Rust 1.54 release notes should be updated to say that this doesn't work. It currently says Read here for more details with here linking to #83366 which says that this is supported syntax.

[ehuss]

@malaire I have updated the description of #83366 to remove the mentions of #[path].

[Veetaha]

Should we consider this issue resolved then?

[jyn514]

I think it should work, imo it's a bug that it doesn't.

[Nemo157]

Current example error message for searchability:

error: malformed `path` attribute input
 --> src/main.rs:1:1
  |
1 | #[path = concat!(env!("OUT_DIR"), "/zbus_xmlgen_output.rs")]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: must be of the form: `#[path = "file"]`