`Tracking` F# AOT, Trimmability, ILLink

[kant2002]

Note
This is a "meta" issue for tracking purposes, since GitHub does not support special types of issues.
@kant2002 I've converted it to the tracking issue, if you don't mind.

Original description

AOT and trimmability is around the corner, and FSharp has issues with some of these technologies. There visible issues with NativeAOT, but I suspect R2R may AOT less code due to these issues or maybe trimmer keep more code.

Describe the solution you'd like

I would like to create action plan of known issues for NativeAOT and trimmability of generated FSharp code to have smaller steps toward F# ❤️ AOT goal. I would like that reflection-free mode of NativeAOT, as opposed to normal NativeAOT mode where reflection working would be also considered.

Describe alternatives you've considered

Seems to be fsharp/fslang-suggestions#919 reach some conclusion, so I think we should go to action.
Also I consider target just NativeAOT with reflection (default), but seems to be having no-reflection is easy way to uncover issues with trimmability and unnecessary reflection usage in app. I consider that approach more of technique to find issues faster, plus I may have smaller app.

Open issues

• Hello World doesn't work with reflection disabled in NAOT #14355
• System.ArgumentException when publishing trimmed, self-contained app #14873
• printf usage requires a lot of rd.xml boilerplate, like it shows here.
• FSharp.Core.OptimizedClosures.FSharpFunc has recusive generics (?)
• printf "%А" does not work in reflection-free mode. There preliminary work here Reflection free code gen #12960
• Interpolated strings like $"{x}" breaks in reflection-free mode.
• Ensure that FSharp.Core is trimmable. #12819
• Tail opcode being emitted for normal methods, destroys JIT optimizations #6329
• A function calling Assembly.GetExecutingAssembly() gets inlined across assembly boundaries #9283

[charlesroddie]

I'll make a start on the RFC this weekend (reflection free codegen).

What is the "recursive generics" issue? Does it manifest in non-string-related code? If not, then this issue is a subset of the other one on string functions.

[kant2002]

@charlesroddie the recursive generic issue can be triggered by printf I suppose, but I can reproduce with Array2D.init 2 3 (fun i j -> i + j) and ILC would print scary warning. Sample which I give, does not crash app, but I maybe I did not put enough efforts into trying. Maybe @MichalStrehovsky can tell us - does issue with recursive generics crash some sample app of him, or not?

[MichalStrehovsky]

Maybe @MichalStrehovsky can tell us - does issue with recursive generics crash some sample app of him, or not?

You can make generic recursion crash something at runtime. I'm not too keen on fiddling with F# to find it, but here's some C#:

System.Console.WriteLine(Count<int>(3));
System.Console.WriteLine(Count<int>(100));

static int Count<T>(int i) =>
    i switch
    {
        0 => 0,
        _ => 1 + Count<Foo<T>>(i - 1)
    };

struct Foo<T> { }

This will print following warning at compile time:

ILC: AOT analysis warning IL3054: Program.<<Main>$>g__Count|0_0<Foo`1<Foo`1<Foo`1<Foo`1<Int32>>>>>(Int32): Generic expansion to 'Program.<<Main>$>g__Count|0_0<Foo`1<Foo`1<Foo`1<Foo`1<Foo`1<Int32>>>>>>(Int32)' was aborted due to generic recursion. An exception will be thrown at runtime if this codepath is ever reached. Generic recursion also negatively affects compilation speed and the size of the compilation output. It is advisable to remove the source of the generic recursion by restructuring the program around the source of recursion. The source of generic recursion might include: 'Program.<<Main>$>g__Count|0_0<T>(Int32)'

The at runtime, the first call will succeed and print the number (because the depth was sufficiently low), but throws for the second call:

3
Unhandled Exception: System.TypeLoadException: Could not load type 'Program' from assembly 'repro, Version=7.0.0.0, Culture=neutral, PublicKeyToken=null'.
   at Internal.Runtime.CompilerHelpers.ThrowHelpers.ThrowTypeLoadExceptionWithArgument(ExceptionStringID, String, String, String) + 0x42
   at Program.<<Main>$>g__Count|0_0[T](Int32) + 0x29
   at Program.<<Main>$>g__Count|0_0[T](Int32) + 0x3c
   at Program.<<Main>$>g__Count|0_0[T](Int32) + 0x3c
   at Program.<<Main>$>g__Count|0_0[T](Int32) + 0x3c
   at Program.<<Main>$>g__Count|0_0[T](Int32) + 0x3c
   at Program.<Main>$(String[]) + 0x2f

[MichalStrehovsky]

Interpolated strings like $"{x}" breaks in reflection-free mode.

We don't make any effort in the dotnet/runtime repo to make libraries work with reflection-free mode, besides no-brainer easy fixes that would be accepted even without reflection-free mode. Reflection-free mode things should ideally be separate issues that either have a no-brainer easy fix that would be acceptable even without the NativeAOT reflection-free mode as a motivating scenario, or can be easily Won't fixed as undesirable.