Formatting doesn't work with WSL2 hosted files in VS2022

Nekroido commented 2 years ago

Steps to reproduce:

Create or open a solution/project hosted in WSL2;
Open a .fs file you wish to format;
Format the file with Edit > Advanced > Format Document.

Expected result:

The file is formatted according to the code style.

Actual result:

Nothing happens and no changes are introduced to the file.

Note:

Formatting works fine when I open projects in Windows host. Fantomas-tool is installed in both hosts and I can format files through both PowerShell in Windows and ZSH in WSL2 Debian.

deviousasti commented 2 years ago

Hey @Nekroido, Sorry for the delayed reply. I suspect it could be a permissions issue. Here's the issue I'm seeing:

Fantomas.Client tried to run dotnet tool list but exited with code 1. File dotnet-tools.json came from another computer and might be blocked to help protect this computer. For more information, including how to unblock, see https://aka.ms/motw

If there's a dotnet tool version defined in dotnet-tools.json, Fantomas tries to use that specific version.

deviousasti commented 2 years ago

It will work if there's no tool manifest defined - with the globally installed formatter.

Nekroido commented 2 years ago

Hi! Sorry, looks like I never pressed the "Comment" button. I do have the manifest file, but only with the paket entry. The error I see in my "Output: F# Formatting" is this:

The operation is not supported:
 The FantomasResponseCode value '11' is unexpected.

nojaf commented 2 years ago

Hello, Code '11' means that Fantomas daemon (your global or local tool) could not be started. Can you execute:

open System
open System.IO

let userProfile = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile)
Path.Combine(userProfile, ".dotnet", "tools", "fantomas.exe")

in a F# interactive session (dotnet fsi) and verify that the path that comes out of there exists.

Nekroido commented 2 years ago

The path exists in the Windows host. It also exists in my Debian host but without the .exe extension.

nojaf commented 2 years ago

Alright, can you execute the exe in the command line? You shouldn't see anything, but if that crashes, that already tells us something.

Nekroido commented 2 years ago

Both executables exit with Input path is missing...

nojaf commented 2 years ago

Ah apologies, you need to add the --daemon flag. So C:\fullPath\fantomas.exe --daemon

Nekroido commented 2 years ago

Both executables wait for the input and crash with the following trace when I press Enter:

Unhandled exception. StreamJsonRpc.BadRpcHeaderException: No Content-Length header detected.
   at StreamJsonRpc.HeaderDelimitedMessageHandler.ReadCoreAsync(CancellationToken cancellationToken)
   at StreamJsonRpc.MessageHandlerBase.ReadAsync(CancellationToken cancellationToken)
   at StreamJsonRpc.JsonRpc.ReadAndHandleRequestsAsync()
   at Program.main(String[] argv) in C:\Users\nojaf\Projects\fantomas\src\Fantomas.CoreGlobalTool\Program.fs:line 441

nojaf commented 2 years ago

Yeah, that sounds about right. The error you get when pressing enter makes sense. So, I can conclude here that the daemon can be started but not programmatically on your end. There could be a bug in Fantomas.Client.

Could you create a script file with:

#r "nuget: Fantomas.Client"

open System.IO
open Fantomas.Client.Contracts
open Fantomas.Client.LSPFantomasService

let service = new LSPFantomasService() :> FantomasService

// TODO: change file path to existing file on your machine
let file = @"C:\Users\nojaf\Projects\HelloWorld\Math.fs"
let content = File.ReadAllText file

let response =
    service.FormatDocumentAsync { SourceCode = content; FilePath = file; Config = None }
    |> Async.AwaitTask
    |> Async.RunSynchronously

printfn "%A" response

What does that output?

Nekroido commented 2 years ago

It outputs a formatted document in Windows environment when I provide a valid absolute \\wsl$\Debian\... path. Same for Debian for a /home/... path.

I see the error you mentioned initially if I use \\wsl.localhost\... path.

nojaf commented 2 years ago

Yeah, the behaviour we see is starting to make some sense. Something is going wrong when requests are made with UNIX paths inside the Windows host.