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
Largest PR that remains and has been around for a while.
Entirely re-implements F#'s IL binary reader using System.Reflection.Metadata (SRM) and can be used as a drop-in replacement with the current IL binary reader.
Benefits
Less GC allocations. (There is a benchmark for stress testing the IL reading, see here)
Implementation is roughly less than half that of the current implementation for IL binary reading and is more readable.
Future proof; if .NET metadata format is changed, SRM will be updated reflecting those changes.
Remaining work
The major piece of work left is the IL reader having the ability to properly read field data as a byte array when the field has a RVA.
We have to do this because the F# compiler has the ability to do static linking of assemblies - which means it has to merge all the read field data from across multiple assemblies and put them into one assembly. See here - a comment describes why the current implementation is incorrect
The rest of the work is testing, testing, testing and what is mentioned in the Acceptance Criteria part of the PR description.
There is risk of immediately replacing the IL binary reader; so as an idea, you could keep both implementations and only use the old one as a fallback if the newer one failed - all the while raising a watson if this occurs. If at some point there are no more watsons being raised, then you can delete the old implementation.
Parallelizes type-checking of implementation files if those files have a backing signature file
Benefits
Compile times of large projects that make use of signature files for the majority of their implementation files can receive a substantial performance benefit. FSharp.Compiler.Service is a great example of this, where the perf gain was around ~23% on an i7-10700k.
Adds a CI job that will run a determinism test on FSharp.Compiler.Service and FSharp.Core by building the projects twice and comparing the DLL outputs.
Is necessary before merging other PRs that can impact and/or are critical for determinism.
Benefits
A test the verify the compiler is deterministic when the --deterministic compiler option is used.
Remaining work
Get CI to pass, then verify the outputs of FSharp.Compiler.Service and FSharp.Core DLLs manually.
This is a straight-forward PR that does some refactoring for the navigation mechanisms in Visual Studio. The current issue that needs to be resolved is getting the WorkspaceTests to pass - it is currently failing because MEF is unable to resolve the interface IWorkspaceProjectContextFactory for FSharpMetadataAsSourceService, as the interface is only implemented in Visual Studio. We may have to re-think exactly how we can do this, but the PR itself isn't critical; it is just much nicer to have one place where the navigation logic lives.
The text was updated successfully, but these errors were encountered:
The following are the remaining WIP PRs that I have:
System.Reflection.Metadata
(SRM) and can be used as a drop-in replacement with the current IL binary reader.--refonly
and--refout:<file>
.--deterministic
compiler option is used.WorkspaceTests
to pass - it is currently failing because MEF is unable to resolve the interfaceIWorkspaceProjectContextFactory
forFSharpMetadataAsSourceService
, as the interface is only implemented in Visual Studio. We may have to re-think exactly how we can do this, but the PR itself isn't critical; it is just much nicer to have one place where the navigation logic lives.The text was updated successfully, but these errors were encountered: