Resumable state machines: Don't capture definitions by "builder@" prefix. EXPERIMENTAL

[majocha]

AI says: Refactored LowerStateMachines.fs to identify state machine binding variables using only "expand var" or member "this" checks, removing the "builder@" name prefix logic. Updated TaskGeneratedCode.fs to align the generated IL for Generic1InGeneric1<'T>.run with the new binding logic, introducing a TaskBuilder local and adjusting closure variable handling.

Description

I don't yet have a good small repro.
Situations of mixed use of both resumable and standard computation expressions can in some rare cases result in:

error FS0971: Undefined value 'builder@'

on a non-resumable CE let binding.

It is not clear to me why there's a need to special case builder@ vals during state machine lowering. Some builders may not be resuamble and are erroneously added to ResumableCodeDefns.

This is an experiment to eliminate the string prefix "builder@" logic to see if things still work.

[github-actions]

❗ Release notes required

@majocha,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md	No release notes found or release notes format is not correct

[majocha]

this getter call is the only substantial change in the IL. It gets eliminated with "--optimize+"

[T-Gro]

Do we know why it was needed before?
Are the recent state machine bug fixes the reason why we no longer need this special casing?

[majocha]

Are the recent state machine bug fixes the reason why we no longer need this special casing?

No, this is completely independent. I did a checkout of old commit and applied this fix to check it.

Do we know why it was needed before?

Ha, this is not entirely clear. That's why I'm a bit wary about this.

[majocha]

OK, before, it eliminates the whole desugared builder code:

----------- OVERALL EXPRESSION FOR STATE MACHINE CONVERSION ----------------------
let builder@ =
      task
let _ =
      builder@
let code =
      let _ =
            builder@
      let generator =
            fun unitVar -> ...

After, it leaves the let builder@ = task dangling:

----------- OVERALL EXPRESSION FOR STATE MACHINE CONVERSION ----------------------
let _ =
      builder@
let code =
      let _ =
            builder@
      let generator =
            fun unitVar ->

This clears up the purpose of the "builder@" special casing.

[majocha]

It seems the goal of

    (let nm = v.LogicalName
     (nm.StartsWithOrdinal("builder@") || v.IsMemberThisVal))

was just to eliminate these bindings generated during CE compilation

let builder@ =
      task
let _ =
      builder@

But aren't they are optimized out of existence anyway?