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

Extract into function should preserve existing parameter order #18639

Closed
emilk opened this issue Dec 9, 2024 · 3 comments · Fixed by #18656
Closed

Extract into function should preserve existing parameter order #18639

emilk opened this issue Dec 9, 2024 · 3 comments · Fixed by #18656
Assignees
Labels
A-assists C-enhancement Category: enhancement

Comments

@emilk
Copy link

emilk commented Dec 9, 2024

Problem

I often have a list of similar "context" parameters to my functions, and I try to be consistent with their order. For example:

fn foo_ui(ctx: &Context, ui: &mut Ui, foo: &Foo) {}

fn bar_ui(ctx: &Context, ui: &mut Ui, bar: &Bar, option: Option) {}

When calling "Extract to function" on some code, Rust analyzer ignores this parameter order and I often end up with functions where I need to manually rearrange the parameter order to my liking.

Suggested solution

When "Extract to function" decides the parameter order of the new function, it should use the following algorithm:

A) Categorize the arguments based on wether or not they were parameters to the already existing function
B) If yes, put them first, and in the same order as in the existing function
C) if no, put them last, in whatever order (I have no strong opinion here - can use same heuristic as the current code)

Effect

fn existing(a: A, b: B, c: C) {
    let x = 32;
    let y = 1.0;

    long_code_block_that_uses(x,b,a,y) // <--- call "Extract to function" on this code block
}

Results in ->

fn existing(a: A, b: B, c: C) {
    let x = 32;
    let y = 1.0;
    fun(a, b, x, y);
}

fn fun(a: A, b: B, x: i32, y: f32) {
    long_code_block_that_uses(x,b,a,y)
}
@emilk emilk added the C-feature Category: feature request label Dec 9, 2024
@Veykril
Copy link
Member

Veykril commented Dec 9, 2024

C) if no, put them last, in whatever order (I have no strong opinion here - can use same heuristic as the current code)

The current emitted ordering is dependent on appearance order in the extracted snippet, so we probably want to use that for C) here as well. Generally agree though, the assist should preserve parent function parameter ordering where possible!

@Veykril Veykril added A-assists C-enhancement Category: enhancement and removed C-feature Category: feature request labels Dec 9, 2024
@roife roife self-assigned this Dec 9, 2024
@roife
Copy link
Member

roife commented Dec 9, 2024

Since we would lower params in order, can we sort locals by binding_id here?

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub struct Local {
pub(crate) parent: DefWithBodyId,
pub(crate) binding_id: BindingId,
}

@Veykril
Copy link
Member

Veykril commented Dec 10, 2024

We could probably do that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-assists C-enhancement Category: enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants