Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Macro in path attribute on module results in file not found error #48250

Closed
CasualX opened this issue Feb 16, 2018 · 4 comments
Closed

Macro in path attribute on module results in file not found error #48250

CasualX opened this issue Feb 16, 2018 · 4 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros-2.0 Area: Declarative macros 2.0 (#39412) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@CasualX
Copy link

CasualX commented Feb 16, 2018

When using a build script to generate code I tried to include it in a submodule in the following way:

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

However this results in error[E0583]: file not found for module generated. The error does not display the actual path it tried to access.

The closes related issue I could find are #18849 and rust-lang/rfcs#1516 (related rust-lang/cargo#824). However all of these talk about the compile error being a parse error, while I'm getting an error about file not being found.

For reference, here's the build script: (abridged, I apologize if this doesn't compile but you get the idea)

use std::{env, fs};
use std::path::PathBuf;

fn main() {
	let out_dir = PathBuf::from(env::var_os("OUT_DIR").expect("OUT_DIR not set"));
	let mut file = fs::File::create(&out_dir.join("/generated.cs")).expect("Failed to create generated.rs");
	let _ = writeln!(file, "pub const FOO: i32 = 42;");
}

The include! macro works mostly but has one annoying problem that top-level inner attributes causes a compile error: #18810

The unexpected and reason why I don't think this is a duplicate issue is that the compile error has changed. From the error rust reports it appears I've made a simple typo in the path when in fact this feature is simply not supported.

@pietroalbini
Copy link
Member

There is a new RFC that aims to provide a way to solve this issue: rust-lang/rfcs#2320.

@pietroalbini pietroalbini added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-macros-2.0 Area: Declarative macros 2.0 (#39412) labels Feb 20, 2018
@durka
Copy link
Contributor

durka commented Mar 3, 2018

@pietroalbini can you clarify how #2320 addresses this issue? Would built-in attributes such as #[path] be upgraded to use this new macro expansion API?

@pietroalbini
Copy link
Member

@durka it doesn't directly mention it, but it provides the tools to implement it.

rubdos added a commit to whisperfish/libsignal-service-rs that referenced this issue Jun 18, 2020
It would be cleaner to yield the compiled files OUT_DIR, but that gets
ugly very fast because of
rust-lang/rust#48250.
rubdos added a commit to whisperfish/libsignal-service-rs that referenced this issue Jun 18, 2020
It would be cleaner to yield the compiled files OUT_DIR, but that gets
ugly very fast because of
rust-lang/rust#48250.
rubdos added a commit to whisperfish/libsignal-service-rs that referenced this issue Jun 18, 2020
It would be cleaner to yield the compiled files OUT_DIR, but that gets
ugly very fast because of
rust-lang/rust#48250.
rubdos added a commit to whisperfish/libsignal-service-rs that referenced this issue Jun 20, 2020
It would be cleaner to yield the compiled files OUT_DIR, but that gets
ugly very fast because of
rust-lang/rust#48250.
rubdos added a commit to whisperfish/libsignal-service-rs that referenced this issue Jun 20, 2020
It would be cleaner to yield the compiled files OUT_DIR, but that gets
ugly very fast because of
rust-lang/rust#48250.
@oskgo
Copy link
Contributor

oskgo commented Jan 24, 2024

I believe this should be closed now. The diagnostic issue was fixed in #88680, which also added a suitable test.

For the feature request of actually making this work there's #87681.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros-2.0 Area: Declarative macros 2.0 (#39412) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants