You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These are major holes in the F# experience and should be implemented.
507
-
508
-
### Missing debug emit for F# Interactive
509
-
510
-
For F# Interactive [we do not currently emit debug information for script code](https://github.com/dotnet/fsharp/issues/5457). This is because of a missing piece of functionality in the Reflection.Emit APIs, and means we have to change our approach to emitting code fragments in F# Interactive to no longer use dynamic assemblies.
F# Interactive (`dotnet fsi`) accepts incremental code fragments. This capability is also used by [hosted execution capability of the FSharp.Compiler.Service API](fcs/interactive.fsx) which is used to build the F# kernel for .NET Interactive notebooks.
10
+
11
+
Historically F# Interactive code was emitted into a single dynamic assembly using Reflection.Emit and ilreflect.fs (meaning one assembly that is continually growing). However, .NET Core Reflection.Emit does not support the emit of debug symbols for dynamic assemblies, so in Feb 2022 we switched to emitting multiple non-dynamic assemblies (meaning assemblies dynamically created in-memory using ilwrite.fs, and loaded, but not growing).
12
+
13
+
The assemblies are named:
14
+
15
+
`FSI-ASSEMBLY1`
16
+
`FSI-ASSEMBLY2`
17
+
18
+
etc.
19
+
20
+
## Compat switch
21
+
22
+
There is a switch `fsi --multiemit` that turns on the use of multi-assembly generation (when it is off, we use Reflection Emit for single-dynamic-assembly generation). This is on by default for .NET Core, and off by default for .NET Framework for compat reasons.
23
+
24
+
## Are multiple assemblies too costly?
25
+
26
+
There is general assumption in this that on modern dev machines (where users execute multiple interactions) then generating 50, 100 or 1,000 or 10,000 dynamic assemblies by repeated manual execution of code is not a problem: the extra overheads of multiple assemblies compared to one dynamic assembly is of no real significance in developer REPL scenarios given the vast amount of memory available on modern 64-bit machines.
27
+
28
+
Quick check: adding 10,000 `let x = 1;;` interactions to .NET Core `dotnet fsi` adds about 300MB to the FSI.EXE process, meaning 30K/interaction. A budget of 1GB for interactive fragments (reasonable on a 64-bit machine), and an expected maximum of 10000 fragments before restart (that's a lot!), then each fragment can take up to 100K. This is well below the cost of a new assembly.
29
+
30
+
Additionally, these costs are not substantially reduced if `--multiemit` is disabled, so they've always been the approximate costs of F# Interactive fragment generation.
31
+
32
+
## Internals and accessibility across fragments
33
+
34
+
Generating into multiple assemblies raises issues for some things that are assembly bound such as "internals" accessibility. In a first iteration of this we had a failing case here:
// Fragment 1 - not `x` becomes an internal field of the class
55
+
> type C() =
56
+
> let mutable x = 1
57
+
> member _.M() = x
58
+
> ;;
59
+
...
60
+
// Fragment 2 - inlining 'M()' gave an access to the internal field `x`
61
+
> C().M();;
62
+
...<bang>...
63
+
```
64
+
65
+
According to the current F# scripting programming model (the one checked in the editor), the "internal" thing should be accessible in subsequent fragments. Should this be changed? No:
66
+
67
+
* It's very hard to adjust the implementation of the editor scripting model to consider fragments delimited by `;;` to be different assemblies, whether in the editor or in F# Interactive.
68
+
* And would we even want to? It's common enough for people to debug code scattered with "internal" declarations.
69
+
* In scripts, the `;;` aren't actually accurate markers for what will or won't be sent to F# Interactive, which get added implicitly.
70
+
71
+
For example, consider the script
72
+
73
+
```fsharp
74
+
let internal f() = 1;;
75
+
f();;
76
+
```
77
+
78
+
In the editor should this be given an error or not? That is, should the `;;` be seen as accurate indicators of separate script fragments? (Answer: yes if we know the script will be piped-to-input, no if the script is used as a single file entry - when the `;;` are ignored)
79
+
80
+
* Further, this would be a breaking change, e.g. it could arise in an automated compat situation if people are piping into standard input and the input contains `;;` markers.
81
+
82
+
Because of this we emit IVTs for the next 30 `FSI-ASSEMBLYnnn` assemblies on each assembly fragment, giving a warning when an internal thing is accessed across assembly boundaries within that 30 (reporting it as a deprecated feature), and give an error if internal access happens after that.
83
+
84
+
From a compat perspective this seems reasonable, and the compat flag is available to return the whole system to generate-one-assembly behavior.
0 commit comments