debug notes.md

Some notes on debug stuff

Notes for Kathleen and Vlad.

Two techniques to fix things like 11262

1. Hack the generated IL

e.g. we want y in scope when stopped at x + 1:

let f (x, y) = 
    data |> List.map (fun x -> 
        let (* IL local *) y = y // Hack the IL
        x + 1)

We already do this for the this pointer:

type C() = 
    member x.M() = 
        let (* IL local *) x = this  // Hack the generated IL: Hidden debug codegen (done today) 
        x.ToString()

2. Do it "properly"

Doing it "properly" might mean having extra PDB tables, e.g. to record the name of the this pointer, and having an F#-specific debug engine (or make a mod to the C#/VB engine) know about this data:

type C() = 
    member x.M() = 
        PDB: ARGUMENT SCOPE TABLE: THIS POINTER  --> "x" //Proper:  PDB gen + debug engine  
        x.ToString()    <---  debug engine knows what to do 

Possible sequencing of work to develop capabilities towards a debug engine

----Don's expertise----

1. Fix what we can fix by hacking the debug IL and PDB (#11262, #3759?) <--- Don's expertise

----Definitely not Don's expertise----

2. Co-build Roslyn, install into RoslynDev, learn how to debug into Roslyn from Visual Studio F# tools
3. Make a fix to Roslyn (#12409, #1003?)
4. Add a no-op debug engine to Visual Studio F#, e.g. empty inherit from C# Roslyn one // VisualFSharpFull.vsix
5. Experiment with a tiny functionality mod to debug engine
6. Start to fill out engine capabilities

   • Implement an expression evaluator for some F#-specific case Maybe by translating F# to C# and reusing C# expression evaluator

   • Implement F#-specific binder (unclear what this would fix though) e.g. add a debug table to PDB and use it in F# expression evaluator

   • Implement F#-specific logic for stepping (e.g. for computation expressions)

   • e.g. add a stepping table to indicate where a step-over should be a step-into

   • Implement Autos window (#4271)