-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)C-bugCategory: This is a bug.Category: This is a bug.
Description
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
Metadata
Metadata
Assignees
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)C-bugCategory: This is a bug.Category: This is a bug.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
ehuss commentedon Aug 1, 2021
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 duringlowering 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 commentedon Aug 2, 2021
@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 commentedon Aug 2, 2021
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.#[path]
example from 1.54 blog post. rust-lang/blog.rust-lang.org#882Mark-Simulacrum commentedon Aug 2, 2021
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 commentedon Aug 2, 2021
@Mark-Simulacrum
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 itemm
, which is performed before any nested expansions (including expansions inside attributes).+1
N3xed commentedon Aug 15, 2021
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:Change bindings inclusion
ehuss commentedon Aug 15, 2021
Posted #88057 to update the RELEASES, thanks for catching that!
Rollup merge of rust-lang#88057 - ehuss:releases-doc-macros, r=Mark-S…
Rollup merge of rust-lang#88057 - ehuss:releases-doc-macros, r=Mark-S…
ehuss commentedon Sep 6, 2021
Posted #88680 to add errors when attempting to use macros with
#[path]
.malaire commentedon Dec 4, 2021
Rust 1.54 release notes should be updated to say that this doesn't work. It currently says
Read here for more details
withhere
linking to #83366 which says that this is supported syntax.ehuss commentedon Dec 4, 2021
@malaire I have updated the description of #83366 to remove the mentions of
#[path]
.Veetaha commentedon Mar 31, 2022
Should we consider this issue resolved then?
jyn514 commentedon Mar 31, 2022
I think it should work, imo it's a bug that it doesn't.
#[path]
does not accept macro-generated paths #118312Nemo157 commentedon Nov 26, 2023
Current example error message for searchability: