Repository navigation
handle extern crate in name resolution #523
Description
Currently, std::sync::Arc cannot be resolved.
In #522 (comment), @flodiebold speculates:
std::sync gets properly resolved, but it reexports Arc from alloc_crate, which is an extern crate rename: extern crate alloc as alloc_crate. I guess that's the problem.
Here's a simple test case:
diff --git a/crates/ra_ide_api/src/hover.rs b/crates/ra_ide_api/src/hover.rs
index 2968b807..2ca1d6d9 100644
--- a/crates/ra_ide_api/src/hover.rs
+++ b/crates/ra_ide_api/src/hover.rs
@@ -230,6 +230,20 @@ mod tests {
assert_eq!("u32", &type_name);
}
+ #[test]
+ fn test_type_of_arc() {
+ let (analysis, position) = single_file_with_position(
+ r"
+ use std::sync::A<|>rc;
+
+ fn main() {}
+ ",
+ );
+
+ let hover = analysis.hover(position).unwrap().unwrap();
+ assert!(!hover.info.contains("Failed to exactly resolve"));
+ }
+
// FIXME: improve type_of to make this work
#[test]
fn test_type_of_for_expr_1() {
Activity
[-]cannot resolve std::sync::Arc[/-][+]handle `extern crate` in name resolution[/+]matklad commentedon Feb 3, 2019
Shouldn't be too hard to fix:
we should add
extern crates toLoweredModulehere: https://github.com/rust-analyzer/rust-analyzer/blob/581c97a5c3821e247df372f25cf8c01ed514bdd9/crates/ra_hir/src/nameres/lower.rswe should adjust path resolution to take it into account here: https://github.com/rust-analyzer/rust-analyzer/blob/581c97a5c3821e247df372f25cf8c01ed514bdd9/crates/ra_hir/src/nameres.rs
flodiebold commentedon Feb 3, 2019
@matklad I've got a branch which does handle
extern crate(by lowering them to imports with absolute paths), but it doesn't fix this problem, because it turns out we also need to fall back to resolving imports in the crate root. In this particular case, it looks like this:lib.rs:
sync.rs:
In general, even in the 2018 edition, plain paths can be resolved either from the current scope or from the crate root.
matklad commentedon Feb 3, 2019
Just checked locally, and it seems that on 2018
::foooruse foodon't resolve from the crate root. Could it be thatasinextern crateacts as as renamer of the whole crate?flodiebold commentedon Feb 3, 2019
Hm, you're right, it just works for
extern crateapparently. Butextern crate foo as bardoesn't just rename the crate in the extern prelude, because 1. it only has an effect if it's in the crate root or the current module, and 2. the original name is still usable. Back to reading rustc, I guess...flodiebold commentedon Feb 3, 2019
I think
extern crates in the crate root are special-cased to insert entries in the extern prelude, if I read this correctly:https://github.com/rust-lang/rust/blob/fc6e9a2845e8bb4560811ed21136483a596505bb/src/librustc_resolve/build_reduced_graph.rs#L390-L408
bjorn3 commentedon Feb 3, 2019
Yup, rust-lang/rust#54658
flodiebold commentedon Feb 3, 2019
Though
stdisn't actually a case of this, since it's still edition 2015, but I guess if we implemented it that way we could still avoid implementing 2015 name resolution...Merge #742