Wrong path attribute handling in inline modules

[Lokathor]

This seems related to #3898 but my file is inside the workspace so even if files outside the workspace aren't supported, I think that my use case should be.

I've got a crate that deals with CPU intrinsics. As I'm sure you're aware, x86 and x86_64 are very closely related. I want to write CPU specific modules but also I want to write things once and then use it in both places as much as possible.

This leads to a file system that looks like this:

src/
    intel_family/
        m128_.rs
        sse.rs
    lib.rs

And then a lib.rs that looks like this:

#[cfg(target_arch = "x86")]
pub mod x86 {
  //! Types and functions for safe `x86` intrinsic usage.
  use super::*;
  use core::arch::x86::*;

  #[path = "../intel_family/m128_.rs"]
  mod m128_;
  pub use m128_::*;
  #[path = "../intel_family/sse.rs"]
  mod sse;
  pub use sse::*;
}
#[cfg(target_arch = "x86")]
pub use x86::*;

#[cfg(target_arch = "x86_64")]
pub mod x86_64 {
  //! Types and functions for safe `x86_64` intrinsic usage.
  use super::*;
  use core::arch::x86_64::*;

  #[path = "../intel_family/m128_.rs"]
  mod m128_;
  pub use m128_::*;
  #[path = "../intel_family/sse.rs"]
  mod sse;
  pub use sse::*;
}
#[cfg(target_arch = "x86_64")]
pub use x86_64::*;

Now the compiler itself is totally able to follow those relative paths from the fake x86 directory up one level to src/ and then down into src/intel_family/ and get the code where it's supposed to go. RA just shows fake errors about unresolved module because it doesn't understand.

[flodiebold]

Huh, so the path is relative to a hypothetical src/x86 path instead of the actual path of the file? 🤔

[matklad]

Relevant code: https://github.com/rust-analyzer/rust-analyzer/blob/da1f316b0246ce41d7cb8560181e294089f06ef3/crates/ra_hir_def/src/nameres/mod_resolution.rs

And tests: https://github.com/rust-analyzer/rust-analyzer/blob/da1f316b0246ce41d7cb8560181e294089f06ef3/crates/ra_hir_def/src/nameres/tests/mod_resolution.rs

[flodiebold]

From the tests it looks like we should already do this correctly, so the first step would probably be adding this case as a test to see whether it breaks...

[Lokathor]

@flodiebold yeah, so, what happens is basically like this:

1. We're in src/lib.rs
2. We declare mod x86 inline which (in the compiler's eyes) puts us into a virtual src/x86/ folder (which doesn't really exist on disk)
3. We declare #[path = "../intel_family/m128_.rs"] mod m128_; which makes a module name m128_ and looks for its content in a relative path that's relative to the virtual src/x86/ directory:

• up 1 to src/
• then down one to src/intel_family/ (a real folder)
• and then a file within that directory.

[jonas-schievink]

I'm unable to reproduce this, is there a repo available with the required directory layout? Or maybe this has just been fixed in the meantime

[lnicola]

Could it have been fixed in #9353?

[jonas-schievink]

Seems unlikely, all files are below src in this case

[lnicola]

Ah, right.

[Lokathor]

I can try to remember to check on if this is still a problem, though i think that i have updated the repo to work around this issue.

[Lokathor]

I'm going to just close this. The current version of the crate doesn't seem to have the problem anymore, so I can't reproduce it.