Skip to content

fix: Name resolution failures inside include!d files #18325

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

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 14 additions & 1 deletion crates/hir-def/src/nameres/collector.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1425,7 +1425,20 @@ impl DefCollector<'_> {
tracing::warn!("macro expansion is too deep");
return;
}
let file_id = macro_call_id.as_file();

let loc = macro_call_id.lookup(self.db.upcast());
let file_id = if loc.def.is_include() {
// If the given macro is an builtin `include!` macro, we expand into the included file.
// So we should collect items within it.
if let Some(it) = loc.include_file_id(self.db.upcast(), macro_call_id) {
it.into()
} else {
// This case the file is not exist. Do not collect items
return;
}
} else {
macro_call_id.as_file()
};
Copy link
Member Author

@ShoyuVanilla ShoyuVanilla Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This id mismatch was blocking us from inserting item for usage search

if loc.item_tree_id().file_id() == file_id {

LHS: MacroFileId != RHS: EditionFileId

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder, does it mean we have to make the include!()d file a macro file instead of an EditionedFileId?

Copy link
Member Author

@ShoyuVanilla ShoyuVanilla Oct 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about both directions; making included file into MacroFile as you said and current way and I think that as the ide things triggered from the opened included file are anchored with nodes from EditionedFile, this way would be more intuitive. But I'm not 100% sure about this so I'll rethink about this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I'm afraid that making it a macro file would require us to map between InFile<T> { file_id: Editioned, .. } and InFile<T> { file_id: Macro, .. } back and forth quite often and missing it in one place might cause another error. This PR seems simpler


let item_tree = self.db.file_item_tree(file_id);

Expand Down
16 changes: 13 additions & 3 deletions crates/hir/src/semantics/source_to_def.rs
Original file line number Diff line number Diff line change
Expand Up @@ -104,7 +104,7 @@ use hir_expand::{
};
use rustc_hash::FxHashMap;
use smallvec::SmallVec;
use span::{FileId, MacroFileId};
use span::{EditionedFileId, FileId, MacroFileId};
use stdx::impl_from;
use syntax::{
ast::{self, HasName},
Expand All @@ -118,6 +118,7 @@ pub(super) struct SourceToDefCache {
pub(super) dynmap_cache: FxHashMap<(ChildContainer, HirFileId), DynMap>,
expansion_info_cache: FxHashMap<MacroFileId, ExpansionInfo>,
pub(super) file_to_def_cache: FxHashMap<FileId, SmallVec<[ModuleId; 1]>>,
included_file_cache: FxHashMap<EditionedFileId, MacroFileId>,
}

impl SourceToDefCache {
Expand Down Expand Up @@ -163,7 +164,11 @@ impl SourceToDefCtx<'_, '_> {
.include_macro_invoc(crate_id)
.iter()
.filter(|&&(_, file_id)| file_id == file)
.flat_map(|(call, _)| {
.flat_map(|(call, file_id)| {
self.cache
.included_file_cache
.insert(*file_id, MacroFileId { macro_call_id: *call });

modules(
call.lookup(self.db.upcast())
.kind
Expand Down Expand Up @@ -499,7 +504,12 @@ impl SourceToDefCtx<'_, '_> {
let parent = |this: &mut Self, node: InFile<&SyntaxNode>| match node.value.parent() {
Some(parent) => Some(node.with_value(parent)),
None => {
let macro_file = node.file_id.macro_file()?;
let macro_file = if let Some(macro_file) = node.file_id.macro_file() {
macro_file
} else {
let file_id = node.file_id.file_id()?;
*this.cache.included_file_cache.get(&file_id)?
};
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the current node is inside the include!d file, this recursive parent search was stopped on macro_file()? at the file's outer node.
But if this was None it was fallbacked to the root module. So, it worked fine if the file was include!d to root and caused the weird behaviour #18314 if it was inside a block module.


let expansion_info = this
.cache
Expand Down
43 changes: 43 additions & 0 deletions crates/ide/src/goto_definition.rs
Original file line number Diff line number Diff line change
Expand Up @@ -497,6 +497,49 @@ fn func_in_include() {
//^^^^^^^^^^^^^^^
}

fn foo() {
func_in_include$0();
}
"#,
);
}

#[test]
fn goto_def_in_included_file_inside_mod() {
check(
r#"
//- minicore:include
//- /main.rs

mod a {
include!("b.rs");
}

//- /b.rs
fn func_in_include() {
//^^^^^^^^^^^^^^^
}

fn foo() {
func_in_include$0();
}
"#,
);

check(
r#"
//- minicore:include
//- /main.rs

mod a {
include!("a.rs");
}

//- /a.rs
fn func_in_include() {
//^^^^^^^^^^^^^^^
}

fn foo() {
func_in_include$0();
}
Expand Down
23 changes: 23 additions & 0 deletions crates/ide/src/references.rs
Original file line number Diff line number Diff line change
Expand Up @@ -2750,4 +2750,27 @@ impl Foo {
"#]],
);
}

#[test]
fn goto_ref_on_included_file() {
check(
r#"
//- minicore:include
//- /lib.rs
include!("foo.rs");

fn howdy() {
let _ = FOO;
}

//- /foo.rs
const FOO$0: i32 = 0;
"#,
expect![[r#"
FOO Const FileId(1) 0..19 6..9

FileId(0) 46..49
"#]],
);
}
}