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

Implement renaming for Functions, Constants and Type Variants #4282

Draft
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

GearsDatapacks
Copy link
Member

This PR closes #3259
This is pretty much ready, except for two things:

  • It's missing tests
  • There's an annoying bug to do with module shadowing which I still have to figure out how to resolve

@GearsDatapacks GearsDatapacks force-pushed the cross-module-value-renaming branch 3 times, most recently from d4c87d0 to 1f931b9 Compare February 27, 2025 17:16
@GearsDatapacks
Copy link
Member Author

GearsDatapacks commented Feb 28, 2025

Ok, this is ready for review now. I'm not super happy with the way I fixed the module access shadowing bug, but I couldn't think of another way to do it. Let me know if you have any thoughts.

@GearsDatapacks GearsDatapacks marked this pull request as ready for review February 28, 2025 20:30
Copy link
Member

@lpil lpil left a comment

Choose a reason for hiding this comment

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

Super nice!! I'm really excited about this one.

I've not finished reviewing totally but I've gotta go so I wanted to drop my thoughts so far. See inline notes.

import mod.{Constructor}

pub fn main() {
#(Constructor(75), mod.Constructor(57))
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if when renaming a constructor that has been imported in an unqualified fashion it should alias the import rather than rename it globally.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I wasn't sure about this. Maybe we can ask in Discord and hear other people's opinions on it.

#[derive(Debug, Clone, PartialEq, Eq, Default)]
pub struct References {
pub imported_modules: HashSet<EcoString>,
pub value_references: HashMap<(EcoString, EcoString), Vec<SrcSpan>>,
Copy link
Member

Choose a reason for hiding this comment

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

It seems like it may be challenging to identify unused code with this data structure, and replacing the current broken usage tracking system is one of the main goals of the call graph work. Did you have thoughts on how that'd be done?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's true, I wasn't thinking too much about the current usage tracking. We already generate an in-module call-graph for dependency ordering, so would it be possible to use just that for usage tracking? We can't use that for renaming because it doesn't track cross-module usage.

Copy link
Member

Choose a reason for hiding this comment

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

That one only tracks calls to module functions, which isn't enough for usage detection.

Usage detection, rename, and show-references all require the same thing: knowing all the references for each entity in the code. Usage detection uses this information differently from the other two though, it traverses the graph from all the public entities to find any unreachable nodes.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok that makes sense, thanks.
I'll look into it

@GearsDatapacks GearsDatapacks marked this pull request as draft March 1, 2025 21:53
@GearsDatapacks
Copy link
Member Author

Ok, I have now added the reference information to the cache so we can rename values in cached modules.
It feels a bit wasteful, it's quite a lot of information which is only needed for the LSP, but I don't think there's any other way around it.
I have responded to a couple of your comments, let me know your thoughts.

@GearsDatapacks GearsDatapacks marked this pull request as ready for review March 2, 2025 12:52
@GearsDatapacks GearsDatapacks marked this pull request as draft March 3, 2025 22:35
@GearsDatapacks GearsDatapacks force-pushed the cross-module-value-renaming branch 5 times, most recently from 237dbeb to 08d5d5c Compare March 6, 2025 10:58
@GearsDatapacks GearsDatapacks force-pushed the cross-module-value-renaming branch from 08d5d5c to aa0d57e Compare March 9, 2025 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LSP: rename custom type variant
2 participants