Open Numpsy opened 2 months ago
I appreciate the well-researched suggestion!
I've also been poking at the logging recently, since there are several outstanding issues
The DVar type is used for managing global logger state (like semaphore instances) behind the scenes.
From the poking I've done so far, I think there's a route to de-globalize the logger. That alone might be enough to solve the AOT problem, since it could eliminate DVar. If not, it'd also simplify the route to supporting Microsoft.Extensions.Logging which I'd guess is supported by AOT compile
Microsoft.Extensions.Logging.Abstractions can be used in AOT apps (I have cli tools at work using it for console logging that work in AOT compiles).
On another related note - there are a bunch of places in Expecto that use sprintf
for string formatting, and that can have issues with AOT builds.
Looking at the code, I think at least some of those could be changed to use string interpolation instead which tends to work better, so are there any thoughts or objections on changing that?
I don't see any issue with the sprintf subs you made. It was just interpolating strings, so there shouldn't be any issues with type-specific formatting. It also shouldn't make formatting evaluations any more eager.
In a simple test app, that change seems to be enough to get a
testTask "I am (should fail)" {
"╰〳 ಠ 益 ಠೃ 〵╯" |> Expect.equal true false
}
to run and print out the correct results in a build with simplified logging :-) I still get an error using Expect.equal on records rather than base types, but one thing at once.
Interesting, I wouldn't have expected %s to behave any different than the .ToString() implied in string interpolation.
I believe that some of the issues with (s)printf are down to all the machinery for partial application and such, which interpolation doesn't have so there's less scope for issues (though I don't know why there appears to be some situations where sprintf "%A" int
works in NativeAOT and sprintf "%i" int
throws :-( )
There's also a specific optimization in recent compilers that can convert interpolations that only involve strings into calls to String.Concat which simplifies things - https://github.com/dotnet/fsharp/pull/16556 - though you might still need langVersion set to preview to get that ATM.
I'm not sure how sensible / feasible doing this is, but:
If I try to build the minimal test app from the readme:
as .NET 8.0 using NativeAOT, then the test app fails to run with this exception:
(I've seen a few variations of the call stack with other test apps, depending on if they use runTestsInAssembly or variations like that).
If I build the app with full AOT analysis enabled then I get a few instances of warnings like this:
Which looks like something in the logging setup is generating recursive generics too complicated for the AOT compiler to handle. I don't know anything about how the
DVar
stuff works and haven't investigated any further that this so far, but leaving this here in case anyone else has any ideas about if it's possible to get this to work.