Code action for inlining functions

[domust]

Related to #5808

Given a code like this:

function()
|> result.map(fn(x) { x + 1 })

It would be useful to produce the following output after running a code action:

case function() {
  Ok(x) -> Ok(x + 1)
  Error(_) -> todo
}

This could be viewed as inlining result.map function's body since this is how it is defined:

pub fn map(over result: Result(a, e), with fun: fn(a) -> b) -> Result(b, e) {
  case result {
    Ok(x) -> Ok(fun(x))
    Error(e) -> Error(e)
  }
}

[lpil]

Hello!

When it would this be available?

How would name collisions be handled?

What about anonymous functions passed to the function?

[domust]

Could you also give an example for the case expression bringing new variables into scope?

[domust]

As for the constraint communication to the programmer, I can give an example what gopls does. It has a code action named Show/Hide compiler optimization details for <package>, which is a toggle for adding additional information to the diagnostics. Here's an example of such diagnostic: cannotInlineFunction(function too complex: cost 104 exceeds budget 80).

[lpil]

Shouldn't function parameters shadow the variable names of the outer scope?

Commonly other expressions that are not variables will be used in function calls, like the anonymous function and 0 in this code:

list.fold(items, 0, fn(x) {
  x + 1
})

Could you also give an example for the case expression bringing new variables into scope?

case items {
  [] -> acc
  [first, ..items] -> something(first, items)
}

It has a code action named Show/Hide compiler optimization details for , which is a toggle for adding additional information to the diagnostics. Here's an example of such diagnostic: cannotInlineFunction(function too complex: cost 104 exceeds budget 80).

That's a very interesting idea! What does this end up looking like? Could you show a screenshot? What other information gets presented?

[domust]

That's a very interesting idea! What does this end up looking like? Could you show a screenshot? What other information gets presented?

I'll be using this file as an example: https://github.com/golang/tools/blob/master/txtar/fs.go via https://zed.dev

Screen.Recording.2026-07-08.at.17.47.32.mov

[lpil]

Very cool! What sort of things do people use it for?

Seems like it would be hard for someone to know to and then be able to use that to understand the availability of an inlining code action. :/

[gavinmorrow]

Maybe for naming conflicts (from arguments, not anon fns), it could declare any conflicting arguments at the top of the inlined block. rust-analyzer does this for all arguments when inlining regardless of whether or not there is a naming conflict.

e.g. after inlining wobble,

fn main() {
  let wibble = 42
  let wabble = 10
  wobble(wibble, wabble)
}

fn wobble(foo, bar) {
  let wibble = 22
  echo { wibble + foo + bar }
}

becomes

fn main() {
  let wibble = 42
  let wabble = 10
  {
    let foo = wibble
    let wibble = 22
    echo { wibble + foo + wabble }
  }
}

[gavinmorrow]

With multiple arguments that conflict, it could do a tuple:

fn main() {
  let wibble = 42
  let wabble = 10
  wobble(wibble, wabble)
}

fn wobble(wabble, foo) {
  let wibble = 22
  echo { wibble + wabble + foo }
}

becomes

fn main() {
  let wibble = 42
  let wabble = 10
  {
    let #(wabble, foo) = #(wibble, wabble)
    let wibble = 22
    echo { wibble + wabble + foo }
  }
}

[gavinmorrow]

rust-analyzer apparently just ignores the naming conflict problem with closures:

let this = 5;
let _: Result<_, ()> = Ok(42).map(|num| num + this);

becomes

let this = 5;
let _: Result<_, ()> = {
    let this = Ok(42);
    match this {
        Ok(t) => Ok((|num| num + this)(t)),
        // Errors because `this` ^^^^ has a type of Result, not i32
        Err(e) => Err(e),
    }
}

[gavinmorrow]

Maybe the solution could be the same as the arguments thing above—if there is a naming conflict, define the anon fn at the start of the block in a tuple w/ just like the other arguments.

fn main() {
  let this = 22
  let _ = map(42, fn(num) { num + this })
}

fn map(num, fun) {
  let this = Ok(num)
  case this {
    Ok(x) -> Ok(fun(x))
    Error(err) -> Error(err)
  }
}

becomes

fn main() {
  let this = 22
  let _ = {
    let fun = fn(num) { num + this }
    let this = Ok(42)
    case this {
      Ok(x) -> Ok(fun(x))
      Error(err) -> Error(err)
    }
  }
}