FSharpLint icon indicating copy to clipboard operation
FSharpLint copied to clipboard

FSharpLint is significantly slow for certain .fsproj files

Open sangkilc opened this issue 3 years ago • 12 comments

Description

FSharpLint sometimes hangs when I give a fsproj file as input. When I provide individual fs files in the fsproj as input, then it works well. I am using the latest fsharplint version 0.21.2 and .NET 6.

Repro steps

Make sure you use .NET 6 as the project that I am referring here only compiles with .NET 6.

  1. git clone https://github.com/B2R2-org/B2R2.git
  2. cd B2R2; dotnet build
  3. dotnet tool install -g dotnet-fsharplint
  4. dotnet fsharplint lint src/FrontEnd/BinFile/B2R2.FrontEnd.BinFile.fsproj

In Step 4, you will see that FSharpLint hangs. The tool runs well with other fsproj files, e.g., dotnet fsharplint lint src\Core\B2R2.Core.fsproj works well.

Expected behavior

FSharpLint should run well with any fsproj file.

Actual behavior

It hangs for specific fsproj files such as the one above, and the CPU core usage is ~ 100%. Seems like running in an infinite loop.

Known workarounds

I can input individual fs files in the fsproj file to get around this problem.

Related information

  • Operating system: I can repro this on Windows 11 and Linux Ubuntu 20.
  • Version: dotnet-fsharplint 0.21.2 (installed from the dotnet tool command)
  • .NET Runtime: .NET 6

sangkilc avatar Jul 20 '22 13:07 sangkilc

Have you tested this with other repos (code base)?

janus avatar Aug 11 '22 09:08 janus

Have you tested this with other repos (code base)?

What's the point of this question? He already said it hangs for certain .fsproj files, he didn't say for all .fsproj files.

knocte avatar Aug 11 '22 09:08 knocte

We have some other internal repos that have the same problem, but I don't know of any public one.

After some digging, I observed that fsharplint indeed terminates if I run it for 1-2 hours on a powerful machine; so it is not really hanging. Let me change the title accordingly.

Our current workaround is to just run fsharplint on individual files instead of using an .fsproj file, which works totally fine for us.

sangkilc avatar Aug 11 '22 09:08 sangkilc

We have some other internal repos that have the same problem, but I don't know of any public one.

After some digging, I observed that fsharplint indeed terminates if I run it for 1-2 hours on a powerful machine; so it is not really hanging. Let me change the title accordingly.

Our current workaround is to just run fsharplint on individual files instead of using an .fsproj file, which works totally fine for us.

Thanks for the update. I will look into this issue. It is interesting.

janus avatar Aug 11 '22 09:08 janus

Our current workaround is to just run fsharplint on individual files instead of using an .fsproj file

The problem with this approach is that you're not benefiting from the rules that would use typed-checks.

@sangkilc we have a new prerelease that is completely transitioned to .net6.0 and I have the feeling that it might have some impact on this bug. Do you mind upgrading to it and re-testing? (The latest pre-release: https://www.nuget.org/packages/dotnet-fsharplint/0.23.1--date20231228-0934.git-e8d2697 )

knocte avatar Dec 30 '23 00:12 knocte

Thanks for the input. Unfortunately, I cannot run the latest nuget package on my machine even though I have .NET 6 SDK installed. Simialr problems happen on my Linux machines.

> dotnet tool list -g
Package Id             Version                                    Commands
-----------------------------------------------------------------------------------
dotnet-fsharplint      0.23.1--date20231228-0934.git-e8d2697      dotnet-fsharplint

> dotnet fsharplint
Unhandled exception. System.TypeInitializationException: The type initializer for 'FSharpLint.Console.Program' threw an exception.
 ---> System.TypeInitializationException: The type initializer for '<StartupCode$dotnet-fsharplint>.$FSharpLint.Console.Program' threw an exception.
 ---> System.InvalidOperationException: No instances of MSBuild could be detected.
Try calling RegisterInstance or RegisterMSBuildPath to manually register one.
   at Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults()
   at Ionide.ProjInfo.Init.init() in D:\a\proj-info\proj-info\src\Ionide.ProjInfo\Library.fs:line 17
   at <StartupCode$dotnet-fsharplint>.$FSharpLint.Console.Program..cctor() in /home/runner/work/FSharpLint/FSharpLint/src/FSharpLint.Console/Program.fs:line 144
   --- End of inner exception stack trace ---
   at FSharpLint.Console.Program..cctor()
   --- End of inner exception stack trace ---
   at FSharpLint.Console.Program.main(String[] argv) in /home/runner/work/FSharpLint/FSharpLint/src/FSharpLint.Console/Program.fs:line 148

> dotnet --info
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.8d38d0cc

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.100\

.NET workloads installed:
 Workload version: 8.0.100-manifests.8d38d0cc
 [maui-windows]
   Installation Source: VS 17.8.34330.188
   Manifest Version:    8.0.3/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maui\8.0.3\WorkloadManifest.json
   Install Type:              Msi

 [maccatalyst]
   Installation Source: VS 17.8.34330.188
   Manifest Version:    17.0.8478/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maccatalyst\17.0.8478\WorkloadManifest.json
   Install Type:              Msi

 [ios]
   Installation Source: VS 17.8.34330.188
   Manifest Version:    17.0.8478/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.ios\17.0.8478\WorkloadManifest.json
   Install Type:              Msi

 [android]
   Installation Source: VS 17.8.34330.188
   Manifest Version:    34.0.43/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.android\34.0.43\WorkloadManifest.json
   Install Type:              Msi


Host:
  Version:      8.0.0
  Architecture: x64
  Commit:       5535e31a71

.NET SDKs installed:
  8.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

sangkilc avatar Dec 30 '23 04:12 sangkilc

@sangkilc arghh, that's a different (recent) bug. I'm going to ping you in it to ask you a question about it.

knocte avatar Dec 30 '23 04:12 knocte