dotnet / vscode-csharp

Official C# support for Visual Studio Code
MIT License
2.85k stars 669 forks source link

Problems/error state does not update until file is modified (Mac only) #4867

Open jeffomatic opened 2 years ago

jeffomatic commented 2 years ago

Issue Description

VSCode does not report C# programming errors (problems) either inline or in the Problems pane until the file containing the problem is updated. "Updated" means either modifying the file buffer or saving the file. In other words, if a change to File B causes problems in File A, VSCode will not report the problem until File A is updated.

This issue appears to be MacOS-specific. I was able to reproduce it using both the extension's built-in Mono, as well as the global Mono (6.12.0.140). I'm running MacOS 11.6 on an M1 MacBook Air.

I was not able to reproduce this issue on my Windows machine. If you change File B such that code in File A becomes invalid, the Windows version of VSCode will immediately report problems in File A.

Steps to Reproduce

  1. Use the MacOS version of VSCode, with the C# extension enabled. The choice of Mono (global or built-in) does not seem to matter.
  2. Check out this example repo. It's a barebones "Hello World"-style project.
  3. Open Program.cs and OtherClass.cs.
  4. In OtherClass.cs, comment out the OtherClass.Print() method.
  5. Observe that:
    • No problem is reported for the now-invalid call to OtherClass.Print() in Program.cs.
    • Saving OtherClass.cs has no effect.
    • Similar issues arise if you invalidate the callsite in other ways, such as changing OtherClass.Print to private, adding new parameters, renaming it, etc.
  6. Save Program.cs.
  7. Observe that:
    • The call to OtherClass.Print() in Program.cs now displays (correctly) an inline problem (a red squiggle underline) as well as an entry in the Problems pane.
    • As an alternative to saving Program.cs, typing keystrokes into Program.cs also causes the problem to appear.
    • Interestingly, closing and opening Program.cs does not have the same effect; it seems that you have to perform an action that causes the extension to think that the file contents have changed.

The reverse process shows similar behavior: if you uncomment OtherClass.Print(), the problems reported will not go away until Program.cs is modified again. In other words, this issue causes both false positives and false negatives. In general, it appears that problems state from a file will not be reported unless the file containing invalid code is itself is touched in some way.

Expected Behavior

Changes in OtherClass.cs should immediately cause problems to be reported in Program.cs. This is the behavior of pretty much every other built-in code intelligence package, including:

Having problems reported (at least in open files) as soon as changes are made are an important part of the IDE workflow. If you make a change that causes other files to become invalid, you want to know right away. This bug degrades developer experience considerably.

Actual Behavior

Changes in OtherClass.cs that invalidate code in Program.cs do not trigger problems until Program.cs is modified or saved.

Logs

OmniSharp log

Starting OmniSharp server at 10/31/2021, 11:20:23 AM Target: /Users/jefflee/src/csharp-vscode-test OmniSharp server started. Path: /Users/jefflee/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/run PID: 41971 [info]: OmniSharp.Stdio.Host Starting OmniSharp on MacOS 11.6 (x64) [info]: OmniSharp.Services.DotNetCliService Checking the 'DOTNET_ROOT' environment variable to find a .NET SDK [info]: OmniSharp.Services.DotNetCliService Using the 'dotnet' on the PATH. [info]: OmniSharp.Services.DotNetCliService DotNetPath set to dotnet [info]: OmniSharp.MSBuild.Discovery.MSBuildLocator Located 1 MSBuild instance(s) 1: StandAlone 17.0.0 - "/Users/jefflee/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin" [info]: OmniSharp.MSBuild.Discovery.MSBuildLocator MSBUILD_EXE_PATH environment variable set to '/Users/jefflee/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin/MSBuild.exe' [info]: OmniSharp.MSBuild.Discovery.MSBuildLocator Registered MSBuild instance: StandAlone 17.0.0 - "/Users/jefflee/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin" CscToolExe = csc.exe MSBuildToolsPath = /Users/jefflee/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin CscToolPath = /Users/jefflee/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild/Current/Bin/Roslyn BypassFrameworkInstallChecks = true MSBuildExtensionsPath = /Users/jefflee/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.omnisharp/1.37.16/omnisharp/.msbuild [info]: OmniSharp.WorkspaceInitializer Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpFormattingWorkspaceOptionsProvider, Order: 0 [info]: OmniSharp.WorkspaceInitializer Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.Completion.CompletionOptionsProvider, Order: 0 [info]: OmniSharp.WorkspaceInitializer Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.RenameWorkspaceOptionsProvider, Order: 100 [info]: OmniSharp.WorkspaceInitializer Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.ImplementTypeWorkspaceOptionsProvider, Order: 110 [info]: OmniSharp.WorkspaceInitializer Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.BlockStructureWorkspaceOptionsProvider, Order: 140 [info]: OmniSharp.Cake.CakeProjectSystem Detecting Cake files in '/Users/jefflee/src/csharp-vscode-test'. [info]: OmniSharp.Cake.CakeProjectSystem Could not find any Cake files [info]: OmniSharp.MSBuild.ProjectSystem No solution files found in '/Users/jefflee/src/csharp-vscode-test' [info]: OmniSharp.MSBuild.ProjectManager Queue project update for '/Users/jefflee/src/csharp-vscode-test/csharp-vscode-test.csproj' [info]: OmniSharp.Script.ScriptProjectSystem Detecting CSX files in '/Users/jefflee/src/csharp-vscode-test'. [info]: OmniSharp.Script.ScriptProjectSystem Could not find any CSX files [info]: OmniSharp.WorkspaceInitializer Configuration finished. [info]: OmniSharp.Stdio.Host Omnisharp server running using Stdio at location '/Users/jefflee/src/csharp-vscode-test' on host 41925. [info]: OmniSharp.MSBuild.ProjectManager Loading project: /Users/jefflee/src/csharp-vscode-test/csharp-vscode-test.csproj [info]: OmniSharp.MSBuild.ProjectManager Successfully loaded project file '/Users/jefflee/src/csharp-vscode-test/csharp-vscode-test.csproj'. [info]: OmniSharp.MSBuild.ProjectManager Adding project '/Users/jefflee/src/csharp-vscode-test/csharp-vscode-test.csproj' [info]: OmniSharp.MSBuild.ProjectManager Update project: csharp-vscode-test [info]: OmniSharp.Roslyn.CSharp.Services.Diagnostics.CSharpDiagnosticWorkerWithAnalyzers Solution initialized -> queue all documents for code analysis. Initial document count: 4. Received response for /quickinfo but could not find request.

C# log

The C# log was blank.

Environment information

VSCode version: 1.61.2 C# Extension: 1.23.16

Mono Information OmniSharp using built-in mono
Dotnet Information .NET SDK (reflecting any global.json): Version: 5.0.400 Commit: d61950f9bf Runtime Environment: OS Name: Mac OS X OS Version: 11.0 OS Platform: Darwin RID: osx.11.0-x64 Base Path: /usr/local/share/dotnet/sdk/5.0.400/ Host (useful for support): Version: 5.0.9 Commit: 208e377a53 .NET SDKs installed: 3.1.412 [/usr/local/share/dotnet/sdk] 5.0.301 [/usr/local/share/dotnet/sdk] 5.0.400 [/usr/local/share/dotnet/sdk] .NET runtimes installed: Microsoft.AspNetCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] To install additional .NET runtimes or SDKs: https://aka.ms/dotnet-download
Visual Studio Code Extensions |Extension|Author|Version| |---|---|---| |csharp|ms-dotnettools|1.23.16| |even-better-toml|tamasfe|0.14.2| |githistory|donjayamanne|0.6.19| |gltf-vscode|cesium|2.3.12| |prettify-json|mohsen1|0.0.3| |reddevil-vsc-helpers|jeffanddom-dot-com|0.0.1| |remote-containers|ms-vscode-remote|0.202.5| |remote-ssh|ms-vscode-remote|0.65.8| |remote-ssh-edit|ms-vscode-remote|0.65.8| |rewrap|stkb|1.14.0| |ruby|rebornix|0.28.1| |rust-analyzer|matklad|0.2.792| |shaderlabvscode|amlovey|1.3.2| |theme-monokai-pro-vscode|monokai|1.1.19| |unity-debug|Unity|3.0.2| |unity-tools|Tobiah|1.2.12| |vscode-docker|ms-azuretools|1.17.0| |vscode-eslint|dbaeumer|2.2.2| |vscode-ruby|wingrunr21|0.28.0|;
JoeRobich commented 2 years ago

@jeffomatic I've seen this issue before as well. It seems to affect O# when Roslyn analyzers are enabled. This is something we need to investigate more.

jeffomatic commented 2 years ago

Hi Joe, thanks for the follow-up. Based on your comment, I changed ~/.omnisharp/omnisharp.json so EnableAnalyzersSupport was set to false. Using the same example project as the OP, here's what I observed:

  1. I changed a method definition from public to private.
  2. Nothing shows up in the problems pane.
  3. I switched to an open tab containing a callsite to the method.
  4. After a short delay, the type analysis error showed up in the problems pane.

In particular, item 4 is new behavior relative to the original bug report. When EnableAnalyzersSupport is set to true, you have to save or modify the character buffer in order for problems to show up.

I'm unsure if Item 2 (the fact that problems don't show up until you switch tabs to the file containing the invalidated callsites) should be considered the same bug or a different one. When repeating the same process in Windows, invalid callsites show up in the problems pane as soon as you modify the method definition, which I assume is the intended behavior. Having to tab over to an open buffer to see its problems is better than having to tab over and save it, but it's still not great.

Please let me know if I can dig in any further!

geekley commented 1 year ago

It's not Mac-only. I'm having this issue on Linux too (Kubuntu 23.04 snap). I have analyzers enabled (don't know if that makes a difference).

The problem is: whenever I type, the delay on showing errors makes it show them on wrong locations - when the result arrives, the content has changed and the errors are not updated again. So I gotta type/delete a space char (or save) all the time to fix it, and this is REALLY testing my patience. I thought this would eventually be fixed, since it has been like this for years now.

The expected behavior would be to update the errors after I'm finished typing. If needed, you could wait a delay while I type and update once I stop for e.g. 200 ms and/or cancel the pending compilation whenever contents change, replacing it with a new call.