I was hoping for more details about what they did, and how they did it. To me this was more of a “here is how I interacted with a part of the rust community”.
I get the extract function/method is technically a trivial operation. That is why I was hoping for actual details, as there is a gap between “technically simple” which is just free variable analysis, and making the result economically nice.
I get the extract function/method is technically a trivial operation.
You’d think so, but, in my experience, everything which touches surface syntax, and not just transforms some internal IR, is a molasses of special case. The functionality in question is 2k lines of code:
The reason why it works ok enough is 3k lines of tests that follow.
This has been my general approach to anything user-visible in IDE: accept that it’s going to be horrible and would require way more code than you’d expect, drown the thing in tests, and make sure that complexity does not spill over to unrelated features.
In this case though, part of the problem is that the refactor does an analysis that perhaps could be extracted in some sort of the library, but we weren’t very successful at implementing analysis API which works well in presence of macros: macros break the link between what’s written, and what the resulting semantics is, and, for refactors, it’s not enough to analyze the semantics, you potentially need to transform the pre-expansion source code.
No, I mean I have implemented this behaviour numerous times. I’ve even been asked to implement it for C# on a white board during an MS interview. Extracting a bunch of code from one function and putting it into a standalone function is a very simple mechanical task. If you are happy with some terrible number of parameters. Obviously the language you’re operating on also makes a difference in the absolute difficulty (e.g. what is a free variable in assembly?)
The difficulty is how you make it so the result of the extraction isn’t a horrific mass of parameters.
I always forget to use this feature, as well as some other really nice features that Rust Analyzer and similar powerful language tooling provides. Some like “go to definition”/“go to type definition” I can’t live without, but yeah this one in particular would have saved me probably 15 minutes today alone looking back.
I was hoping for more details about what they did, and how they did it. To me this was more of a “here is how I interacted with a part of the rust community”.
I get the extract function/method is technically a trivial operation. That is why I was hoping for actual details, as there is a gap between “technically simple” which is just free variable analysis, and making the result economically nice.
You’d think so, but, in my experience, everything which touches surface syntax, and not just transforms some internal IR, is a molasses of special case. The functionality in question is 2k lines of code:
https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-assists/src/handlers/extract_function.rs
The reason why it works ok enough is 3k lines of tests that follow.
This has been my general approach to anything user-visible in IDE: accept that it’s going to be horrible and would require way more code than you’d expect, drown the thing in tests, and make sure that complexity does not spill over to unrelated features.
In this case though, part of the problem is that the refactor does an analysis that perhaps could be extracted in some sort of the library, but we weren’t very successful at implementing analysis API which works well in presence of macros: macros break the link between what’s written, and what the resulting semantics is, and, for refactors, it’s not enough to analyze the semantics, you potentially need to transform the pre-expansion source code.
No, I mean I have implemented this behaviour numerous times. I’ve even been asked to implement it for C# on a white board during an MS interview. Extracting a bunch of code from one function and putting it into a standalone function is a very simple mechanical task. If you are happy with some terrible number of parameters. Obviously the language you’re operating on also makes a difference in the absolute difficulty (e.g. what is a free variable in assembly?)
The difficulty is how you make it so the result of the extraction isn’t a horrific mass of parameters.
I always forget to use this feature, as well as some other really nice features that Rust Analyzer and similar powerful language tooling provides. Some like “go to definition”/“go to type definition” I can’t live without, but yeah this one in particular would have saved me probably 15 minutes today alone looking back.