`include!`ing files without `.rs` suffix does not work

[kinnison]

I have a project (https://gitlab.com/subplot/subplot) which has a build.rs which writes a file out to be included into the build.

The file is written out to OUT_DIR (embedded_files.inc)

In my code I have:

static EMBEDDED_FILES: &[(&str, &[u8])] = include!(concat!(env!("OUT_DIR"), "/embedded_files.inc"));

In VSCode, I have that line have the following error shown:

failed to load file `/home/dsilvers/dev-git/subplot/target/debug/build/subplot-a90f1b6ad6ba44a6/out/embedded_files.inc`
rust-analyzer(macro-error)

However, that file very much does exist, so the error is spurious. Is there a way to get rust-analyzer to find this file and stop complaining?

[kinnison]

Oh, and for reference, I do have:

{"rust-analyzer.cargo.runBuildScripts": true}

[jonas-schievink]

I think this happens because we only add files ending in .rs to the VFS, so your file isn't known to rust-analyzer

[kinnison]

Hmm, I feel odd calling it .rs when it's not at least a stand alone item.

Looks like the .rs suffix works though. Is it worth having the VFS opportunistically add stuff in that circumstance, or is that basically not plausible?

[NilsIrl]

I have the same issue, my files end in .ast however they are not generated by a build script.

let expression = include!("../tests/variable.ast");

[kinnison]

Fascinatingly if I use include! in a function, it doesn't get highlighted as a fail to load, consider this main.rs:

static GREETING: &str = include!(concat!(env!("OUT_DIR"), "/foobar.inc"));

fn main() {
    println!(include!(concat!(env!("OUT_DIR"), "/foobar.inc")));
    println!("{}", GREETING);
}

This exhibits the failure to load the include file for the static but not for the println!().

With a `build.rs`:

use std::io::Write;
use std::path::Path;

fn main() {
    let outpath = Path::new(&std::env::var("OUT_DIR").unwrap()).join("foobar.inc");
    let mut fh = std::fs::File::create(outpath).unwrap();
    fh.write_all("\"Hello world\"".as_bytes()).unwrap();
}

[NilsIrl]

How would one go about fixing this? I'd be interested.

BTW: this should probably be renamed to something more descriptive like "failed to load reported for non-.rs files"

[flodiebold]

There is no straightforward fix. We can only include files that are in the virtual file system; we have to limit the set of files in the VFS somehow because loading every file in the workspace would be prohibitively expensive; and we don't know the files that will be included when deciding what to load into the VFS.

• A workaround might be a setting to include additional files (patterns) in the VFS.
• Maybe it'd be possible to have some kind of backchannel where after doing analysis and noticing that we need to include some files that are missing, we add them to the VFS; but that would mean doing the whole analysis again (with a lot of cached results, so maybe not so bad), maybe even multiple rounds of that.
• Or maybe we could somehow load these files into the VFS lazily when needed, but that's probably quite a fundamental change to how the VFS works.

FWIW I'm seeing this in a multi-crate repository (tagged to a commit that exhibits the issue). It appears that RA may be trying to use the wrong path relative to the crate to load the included file? The project(s) build fine with cargo, so the error is simply wrong.

The path in the error message is (relative to repository root):
libretro-rs/target/debug/build/libretro-rs-sys-37adac34f8f4cbf3/out/libretro.rs

But the path I would expect is:
libretro-rs-sys/target/debug/build/libretro-rs-sys-86130f2702103941/out/libretro.rs

However, the path in the error message does exist, since the libretro-rs crate depends on the libretro-rs-sys crate in the same repository. It appears that RA is getting confused and I don't think the solution should involve adding configuration to straighten it out. If cargo can figure it out then RA should be able to as well.

$ cargo build
   Compiling libretro-rs-sys v0.1.0 (/home/adam/Repos/libretro-rs/libretro-rs-sys)
   Compiling libretro-rs v0.1.3 (/home/adam/Repos/libretro-rs/libretro-rs)
   Compiling example v0.1.0 (/home/adam/Repos/libretro-rs/example)
    Finished dev [unoptimized + debuginfo] target(s) in 0.93s

If this issue is unrelated, I'll make a new issue.

[Veykril]

That is a different issue yes since your file is an rs file