Fantomas V

[nojaf]

Introduction

Over the years Fantomas has been improving, making it usable in more and more codebases. Under the hood, we still do a lot of questionable processing to reconstruct the correct code. It is well known that we use the FSharp Compiler Services to collect our information via the Untyped Abstract Syntax Tree (AST). Alas, we don't always have enough information in the tree and so we resort to finding answers in the F# tokens.

Going forward, we wish to improve the syntax tree so that we can have a more streamlined codebase and have better performance.
Pull requests for this over dotnet/fsharp have been submitted in the past and eventually make it into FCS.
This process works but is time-consuming. The releases of FCS are scarce and unpredictable. There are no hard feelings here, but we wish to explore an alternative way of integrating the compiler in Fantomas.

This issue serves as a meta issue to collect the various aspects of the next major version.
Not everything is known at this point, and what is known can be subjected to change.

Core goals

In essence, the theme of the next major version is having a better syntax tree. And we need to make some fundamental (and potentially breaking) changes to get there. We want to improve the syntax tree on dotnet/fsharp side and eat our cake on Fantomas side shortly afterwards.

Community goals

Next to our core goals, we also wish to provide a stage where the community can address #1408. This setting still has open questions and we wish to engage the community to pick this up as part of version five.

Breaking changes

A major version allows for breaking changes. We will address certain topics, that we otherwise couldn't due to semantic versioning.
Of course, with a focus on keeping the impact for end-users to a minimum.

Proposed scope

Change

• We would no longer use the FCS NuGet package and grab the F# compiler from the source files instead, Use F# compiler from the source files #2217
• Revisit the Elmish settings as part of the community goals, Revisit Elmish code #2180
• Rename Fantomas to Fantomas.Core and fantomas-tool to fantomas, Rename Fantomas to Fantomas.Core and fantomas-tool to fantomas #2174
• Move to net6, Update .NET tool to net6 #2172

Deprecate

• Remove fsharp_semicolon_at_end_of_line, Remove fsharp_semicolon_at_end_of_line #2247
• Remove fsharp_keep_if_then_in_same_line, Remove fsharp_keep_if_then_in_same_line #2248
• Remove fsharp_indent_on_try_with, Remove fsharp_indent_on_try_with #2249
• Revisit all command line tool setting: consider removing --stdin, --stdout, Update command line tool for v5 #2346
• Fantomas.Extras (we might introduce a separate package that exposes the .editorconfig to FormatConfig parsing), Remove Fantomas.Extras #2269

Add

• Setting fsharp_stroustrup_style (name to be discussed in Option for Stroustrup bracket style #1408)

Technical process

All development is now happening on the master branch.

[Smaug123]

Could you please clarify what "grab the F# compiler from the source files instead" means? I don't think I follow; surely you don't mean compiling the F# compiler from source as part of Fantomas?

[nojaf]

Hi there,

surely you don't mean compiling the F# compiler from source as part of Fantomas

Actually, I do mean that, but it is less bad than it sounds.
I'm working on a prototype where I take the relevant source files from the compiler via Paket. We will create our own little FCS layer and only exposes lexing and parsing.

Any recent improvements that are made in the compiler can be picked up immediately by moving the git commit pointer in the paket.dependencies file.

The footprint of our own compiler service is significantly less compared with the full FCS on NuGet.
So, this will benefit performance and most important it will drive us to fix/improve more things on the parser side.

There is some more prose in the documentation folder where I elaborate a bit more. Though some parts are already outdated.

Let me know if you have any further questions.

[alfonsogarciacaro]

For reference Fable has a similar situation, we use a custom build of the FCS compiler based on a fork maintained by @ncave to improve the performance of incremental compilation with Fable. It's probably not the best way to do things but this is how we do it:

• We try to keep the changes to a minimum so there're no conflicts when syncing the fork with the origin
• Removing the FCS parts that are not needed by Fable is not a goal right now
• We don't keep FCS sources in Fable repo, just a binary build. This build has to be referenced from all dependent .fsproj files
• Atm updating is not automated. Whenever there are changes I just build manually the fork and copy the .dlls to Fable repos

Again, this is just for reference in case it helps, probably Fantomas' needs require a different process. Also, please note that this is different from building the Fable Repl which uses yet another fork 😸 in a totally different way (it does remove files, sources are kept in Fable repo and CI builds it every time)>