Non-optimized inlining regression

[kerams]

Since #19548 inline functions are not inlined in debug builds, including those where inlining is not negotiable.

Repro steps

open System
open FSharp.NativeInterop
#nowarn 9

// without inlining the returned Span points at a stack position that is no longer valid
let inline stackalloc<'a when 'a: unmanaged> length =
    Span<'a> (NativePtr.stackalloc<'a> length |> NativePtr.toVoidPtr, length)

let rec clobber n =
    let mutable a = int64 n
    let mutable b = a * 2L
    let mutable c = b * 2L
    let mutable d = c * 2L
    if n > 0 then clobber (n - 1) + int (a + b + c + d) else 0

let demo () =
    let b = stackalloc<char> 3
    b.[0] <- 'a'
    b.[1] <- 'b'
    b.[2] <- 'c'
    clobber 64 |> ignore
    String b

let r = demo ()
printfn "expected: \"abc\" [97; 98; 99]"
printfn "actual:   %A %A" r (r |> Seq.map int |> Seq.toList)

Expected behavior

> dotnet fsi .\stackalloc-inline-repro.fsx
expected: "abc" [97; 98; 99]
actual:   "abc" [97; 98; 99]
> dotnet fsi --optimize- .\stackalloc-inline-repro.fsx
expected: "abc" [97; 98; 99]
actual:   "abc" [97; 98; 99]

Actual behavior

> dotnet fsi .\stackalloc-inline-repro.fsx
expected: "abc" [97; 98; 99]
actual:   "abc" [97; 98; 99]
> dotnet fsi --optimize- .\stackalloc-inline-repro.fsx
expected: "abc" [97; 98; 99]
actual:   "?" [63; 0; 0]

Known workarounds

Optimize debug builds.

Related information

SDK 11.0.100-preview.6.26359.118

[T-Gro]

@auduchinok : Can you take a look please?

[auduchinok]

Yes, thanks, it's on my list 🙂

[smoothdeveloper]

Also hitting this with recent release of VS2026 insider. What is the plan to identify functions that can't be inlined?

In my case it is calling SRTP in a stack of inline functions; which provokes a runtime failure.

[auduchinok]

In my case it is calling SRTP in a stack of inline functions; which provokes a runtime failure.

Could you share a repro look into, please?

[smoothdeveloper]

type LoadMechanism =
    | NoSource
    | BytesSource of byte[]

let loadResource () =
    let mechanisms = [ NoSource; BytesSource [| 1uy; 2uy; 3uy |] ]
    // Closes over `mechanisms` from the enclosing scope instead of taking it as a parameter --
    let inline makeTypedCsvLoader loadStream mkResult =
        mechanisms
        |> Seq.choose (fun m ->
            let loadStream = loadStream >> Array.map int
            match m with
            | NoSource -> None
            | BytesSource bytes -> Some(loadStream bytes))
        |> Seq.tryHead
        |> Option.map mkResult
    makeTypedCsvLoader id id

[<EntryPoint>]
let main _ =
    let expected = Some [| 1; 2; 3 |]
    let actual = loadResource ()
    printfn "expected: %A" expected
    printfn "actual:   %A" actual
    if actual = expected then
        printfn "OK"
        0
    else
        printfn "MISMATCH (unexpected on this compiler -- bug may be fixed)"
        1

With current VS2026 insider compiler, targetting net48, in debug, mechanisms end up being null rather than closing over the outer scope value.

Unhandled Exception: System.ArgumentNullException: Value cannot be null.
Parameter name: source
at Microsoft.FSharp.Collections.SeqModule.Choose[T,TResult](FSharpFunc2 chooser, IEnumerable1 source) in D:\a_work\1\s\src\FSharp.Core\seq.fs:line 777
at Program.__debug@69(FSharpFunc2 loadStream, FSharpFunc2 mkResult)

in release it works properly.

[auduchinok]

A smaller repro @kerams's case is this:

let inline stackalloc n =
    Span<char>(NativePtr.stackalloc<char> n |> NativePtr.toVoidPtr, n)

let f () =
    let b = stackalloc 1
    b.[0] <- 'a'
    String b

In addition to enabling the optimizations, here are two more workarounds:

• use --always-inline+ in the project
• mark the function with NoDynamicInvocation

There are several ways to tackle this. One way is to propagate force-inlining when an inline function uses any functions marked with NoDynamicInvocation. This would fix this case, but it would silently break the debugger improvements from #19548 which is not good.

Another way is to ask the users to mark such functions with NoDynamicInvocation explicitly: this way adds churn to the user codebases, but it makes the intent clear and communicates the debugging expectations to both users and IDEs. This can be done by adding a new compiler warning when a function not marked with NoDynamicInvocation uses other such functions.

There's a trade off in either option, so I'd like to hear more opinions.

[auduchinok]

@smoothdeveloper Thanks! It looks like a genuine bug. I'm looking into it.