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

Conversation

ShoyuVanilla
Copy link
Member

Fixes #18313 and fixes #18314

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 17, 2024
}
} 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

} 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.

Copy link
Member

@Veykril Veykril left a comment

Choose a reason for hiding this comment

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

So we basically skip expanding include and instead just use the actual file for name resolution? I feel like this might break things

@ShoyuVanilla
Copy link
Member Author

So we basically skip expanding include and instead just use the actual file for name resolution? I feel like this might break things

Well, this doesn't skip expanding but just changes the nameress collecting source.
But as this seems somewhat confusing, I'll rethink of this as ChayimFriedman said 🤔

@ShoyuVanilla ShoyuVanilla marked this pull request as draft October 21, 2024 14:14
@Veykril
Copy link
Member

Veykril commented Oct 21, 2024

I think I know where to fix this actually, the macro token descension logic is wrong / needs to handle this

@bors bors closed this in 487152b Oct 21, 2024
lnicola pushed a commit to lnicola/rust that referenced this pull request Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
4 participants