-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Resolve external preludes for modules inside blocks #17057
Comments
Sorry... I open the issue with I added rust-analyzer/crates/hir-def/src/nameres/collector.rs Lines 367 to 384 in 07ae540
rust-analyzer/crates/hir-def/src/nameres/path_resolution.rs Lines 473 to 477 in 07ae540
rust-analyzer/crates/hir-def/src/nameres/path_resolution.rs Lines 518 to 521 in 07ae540
This resolves the issue, but I don't understand what "so that blocks can properly shadow them" means. |
The shadowing is about stuff like (assuming a fn f() {
mod core {
pub fn foo () {}
}
core::foo();
} This should look into the local module, not the prelude. |
The problem with that approach might be that it fails for nsted block def maps fn foo() {
mod core { mod mem { fn drop<T>(_: T) {} } }
{
use self as _; // forces a block def map here
core::mem::drop(0); // should resolve to the local item, not the prelude one
}
} |
fix: resolve extern prelude for local mods in block modules fix rust-lang/rust-analyzer#17057, rust-lang/rust-analyzer#17032. We should use `ModuleOrigin` to check if the current module is a pseudo-module introduced by blocks (where names might be shadowed), rather than checking `block_def_map`.
The original issue was closed by the bot 😅, but we need to resolve this problem.
Originally posted in #17032 (comment)
The text was updated successfully, but these errors were encountered: