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

Non-inline modules not found in crate hierarchy #15965

Closed
Lunderberg opened this issue Nov 26, 2023 · 2 comments
Closed

Non-inline modules not found in crate hierarchy #15965

Lunderberg opened this issue Nov 26, 2023 · 2 comments
Labels
C-bug Category: bug S-unactionable Issue requires feedback, design decisions or is blocked on other work

Comments

@Lunderberg
Copy link

Module files are erroneously marked as not within the crate hierarchy, with the majority of LSP functionality disabled, when the module declaration occurs within the body of a function.

// main.rs
fn main() {
    #[path = "my_mod.rs"]
    mod my_mod;
    my_mod::func();
}

// my_mod.rs
pub fn func() {}

Expected behavior: LSP works within both main.rs and my_mod.rs.

Actual behavior: The first two characters in my_mod.rs have a warning: "file not included in crate hierarchy", and most LSP functionality, including finding of references, is non-functional within my_mod.rs. LSP does work within main.rs, including jump-to-definition on my_mod::func().

rust-analyzer version: Tested on both rust-analyzer 1.74.0 (79e9716 2023-11-13) and rust-analyzer 1.76.0-nightly (37b2813 2023-11-24).

rustc version: Tested on both rustc 1.74.0 (79e9716c9 2023-11-13) and rustc 1.76.0-nightly (37b2813a7 2023-11-24).

relevant settings: N/A

@Lunderberg Lunderberg added the C-bug Category: bug label Nov 26, 2023
@Veykril
Copy link
Member

Veykril commented Nov 26, 2023

Oh god, people actually use local modules?

I don't think we can reasonably support this. To be able to know this information we'd need to eagerly calculate all block def maps which is exactly what we don't wanna do ...

@Veykril Veykril added the S-unactionable Issue requires feedback, design decisions or is blocked on other work label Nov 26, 2023
@Lunderberg
Copy link
Author

Oh god, people actually use local modules?

Thankfully, only rarely. It came up when making a proc macro, as a way to make the module import more hygienic. There's very little documentation that I could find on how they are used, apart from the discussion here that resulted in requiring an explicit #[path = "path/to/module.rs"], so it doesn't sound like a very common case.

That said, it looks like the bug's effect is a bit wider than the initial case I had found. It looks like it also applies to use of the #[path = "..."] attribute inside a module, not just when they occur inside a function.

// main.rs
mod detail {
    #[path = "my_mod.rs"]
    pub mod my_mod;
}
fn main() {
    detail::my_mod::func();
}

If anybody else runs into this, the solution is to pull the module declarations out into the parent space. For now, closing the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug S-unactionable Issue requires feedback, design decisions or is blocked on other work
Projects
None yet
Development

No branches or pull requests

2 participants