-
-
Notifications
You must be signed in to change notification settings - Fork 798
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
base: main
Are you sure you want to change the base?
Implement renaming for Functions, Constants and Type Variants #4282
Conversation
d4c87d0
to
1f931b9
Compare
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. |
There was a problem hiding this 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)) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
compiler-core/src/ast.rs
Outdated
#[derive(Debug, Clone, PartialEq, Eq, Default)] | ||
pub struct References { | ||
pub imported_modules: HashSet<EcoString>, | ||
pub value_references: HashMap<(EcoString, EcoString), Vec<SrcSpan>>, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Ok, I have now added the reference information to the cache so we can rename values in cached modules. |
237dbeb
to
08d5d5c
Compare
08d5d5c
to
aa0d57e
Compare
This PR closes #3259
This is pretty much ready, except for two things: