Open jeffomatic opened 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.
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:
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!
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.
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
Program.cs
andOtherClass.cs
.OtherClass.cs
, comment out theOtherClass.Print()
method.OtherClass.Print()
inProgram.cs
.OtherClass.cs
has no effect.OtherClass.Print
to private, adding new parameters, renaming it, etc.Program.cs
.OtherClass.Print()
inProgram.cs
now displays (correctly) an inline problem (a red squiggle underline) as well as an entry in the Problems pane.Program.cs
, typing keystrokes intoProgram.cs
also causes the problem to appear.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 untilProgram.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 inProgram.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 inProgram.cs
do not trigger problems untilProgram.cs
is modified or saved.Logs
OmniSharp log
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 monoDotnet 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-downloadVisual 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|;