#[path = "../XXXXXX"] attribute on modules gives false unresolved-module error

[WilliamVenner]

Example: https://github.com/WilliamVenner/rust-analyzer-broken-example

Code:

./package/src/main.rs

#[path = "../../silly_mod/mod.rs"]
mod silly_mod;

fn main() {
    silly_mod::hello();
}

./silly_mod/mod.rs

pub fn hello() {
	println!("Hello, world!");
}

[WilliamVenner]

If I try the quick fix, I get this error in console:

ERR Unable to create file 'c:\Users\billy\Documents\GitHub\brokey\silly_mod\mod.rs' that already exists when overwrite flag is not set: Error: Unable to create file 'c:\Users\billy\Documents\GitHub\brokey\silly_mod\mod.rs' that already exists when overwrite flag is not set

[lnicola]

This is a known limitation, I'm not sure if there's already an open issue for it.

[WilliamVenner]

Not one that I could find - is there a reason for this limitation? I noticed there are tests which surprisingly pass with this exact scenario, from what I can gather.

[WilliamVenner]

This test

https://github.com/rust-analyzer/rust-analyzer/blob/1f1a1ce4f57076be38d18f0a6defddb9c690bb1c/crates/hir_def/src/nameres/tests/mod_resolution.rs#L322-L347

[lnicola]

I'm not sure, but maybe we don't load the file.

[lnicola]

Yeah, it seems to work for files that are inside the project. It gets loaded by the VFS once you edit the file, but we still don't resolve the module for some reason.

[jonas-schievink]

I believe that module files need to be part of the same source root at the moment

[kellpossible]

I've also just run into this issue, I guess the more idiomatic way to handle this situation is to make the referenced module into a full blown library referenced by path = "../path/to/module" in Cargo.toml?

[curldivergence]

Hi! I'm also hitting this problem on both stable and nightly. Unfortunately, the solution suggested by @kellpossible won't work for me since I include autogenerated modules in such a way, so putting them all into Cargo.toml would be very messy.
Interestingly, if I change the path to the faulty module to a non-existent and try "quick fix", a new file actually is being created, but is still being marked as error.

Please let me know if I can provide any more info, and in the meantime - is there any way to silence this error locally?

Thanks!

[kellpossible]

@curldivergence my use case sounds similar, auto generated module, I still didn't implement this workaround for the same reason.

[kellpossible]

I see that there is a test which appears to cover this case?

rust-analyzer/crates/hir-def/src/nameres/tests/mod_resolution.rs

Lines 322 to 347 in ba32991

	#[test]
	fn module_resolution_relative_path_outside_root() {
	check(
	r#"
	//- /a/b/c/d/e/main.rs crate:main
	#[path="../../../../../outside.rs"]
	mod foo;
	//- /outside.rs
	mod bar;
	//- /bar.rs
	pub struct Baz;
	"#,
	expect![[r#"
	crate
	foo: t
	crate::foo
	bar: t
	crate::foo::bar
	Baz: t v
	"#]],
	);
	}

[RalfJung]

This issue also affects working on the Rust standard library; it complains about this and this.

@Veykril why is this "unactionable"?

[Veykril]

To my knowledge this is a known shortcoming of our VFS, so this is "unactionable" in the sense that it needs design decisions on how to get around this shortcoming.

[idigdoug]

Setting "rust-analyzer.diagnostics.disabled": [ "unresolved-module" ] makes this mostly tolerable for me.

[RalfJung]

Is there any way to suppress the error? I can live with "unknown" for the module content, but the red squiggles are distracting. :)

Yeah, I have this in my settings

    "rust-analyzer.diagnostics.disabled": [
        "unlinked-file", // I guess for "normal" projects unlinked files are strange, for me they are common
        "missing-match-arm", // https://github.com/rust-lang/rust-analyzer/issues/4896
        "type-mismatch", // https://github.com/rust-lang/rust-analyzer/issues/1109
        "unresolved-module", // https://github.com/rust-lang/rust-analyzer/issues/9173
        "unresolved-extern-crate", // https://github.com/rust-lang/rust-analyzer/issues/12926
    ],

[walksanatora]

Encoutered this same issue
because i have a virutal manifest repo
because i have a shared folder but when I

#[path = "../../shared/schema_generated.rs"]
mod schema_generated;

for reference this file is at /client/src/main.rs
I am annoyed because this is generated and i really would like IntelleSense for the generated code

[RalfJung]

Maybe the error message could be improved? Currently it says "Cannot find module file", but if the user goes looking then the module file is right there, so that's quite confusing.

FWIW the error that needs to be listed in diagnostics.disabled changed to "E0583".

[bmulder-innoseis]

duplicate of #3898