Diagnostics of info/suggestion level severity are ignored by Problems pane and shortcuts

[daleeidd]

Type: Bug

Issue Description

Diagnostics of info/suggestion level severity (ie not error or warning) are ignored by Problems pane and shortcuts.

This use to work with Omnisharp but not with the new system.

I have checked the filter in the Problems pane and Info is enabled.

Steps to Reproduce

1. Open any project with diagnostic suggestions
2. Check problem pane

Expected Behavior

Suggestions are shown the in Problems pane. Problems shortcuts should also cycle over them.

Actual Behavior

They are ignored.

Environment information

VSCode version: 1.81.1 C# Extension: 2.12.19 Using OmniSharp: false

Dotnet Information

.NET SDK: Version: 7.0.400 Commit: 73bf45718d Runtime Environment: OS Name: Mac OS X OS Version: 14.1 OS Platform: Darwin RID: osx-arm64 Base Path: /usr/local/share/dotnet/sdk/7.0.400/ Host: Version: 7.0.10 Architecture: arm64 Commit: a6dbb800a4 .NET SDKs installed: 7.0.306 [/usr/local/share/dotnet/sdk] 7.0.400 [/usr/local/share/dotnet/sdk] .NET runtimes installed: Microsoft.AspNetCore.App 7.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.10 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 7.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.10 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Other architectures found: None Environment variables: Not set global.json file: Not found Learn more: https://aka.ms/dotnet/info Download .NET: https://aka.ms/dotnet/download

Visual Studio Code Extensions

|Extension|Author|Version|Folder Name| |---|---|---|---| |atom-keybindings|ms-vscode|3.3.0|ms-vscode.atom-keybindings-3.3.0| |case-sensitive-add-next|jacobkantzer|0.0.6|jacobkantzer.case-sensitive-add-next-0.0.6| |csdevkit|ms-dotnettools|1.0.14|ms-dotnettools.csdevkit-1.0.14-darwin-arm64| |csharp|ms-dotnettools|2.12.19|ms-dotnettools.csharp-2.12.19-darwin-arm64| |cursor-jump|leonardpauli|0.0.1|leonardpauli.cursor-jump-0.0.1| |EditorConfig|EditorConfig|0.16.4|editorconfig.editorconfig-0.16.4| |gitlens|eamodio|14.5.2|eamodio.gitlens-14.5.2| |gremlins|nhoizey|0.26.0|nhoizey.gremlins-0.26.0| |latex-workshop|James-Yu|9.15.0|james-yu.latex-workshop-9.15.0| |multi-command|ryuta46|1.6.0|ryuta46.multi-command-1.6.0| |vscode-dotnet-runtime|ms-dotnettools|2.0.0|ms-dotnettools.vscode-dotnet-runtime-2.0.0| |vstuc|visualstudiotoolsforunity|0.9.3|visualstudiotoolsforunity.vstuc-0.9.3|;

Extension version: 2.12.19 VS Code version: Code 1.81.1 (Universal) (6c3e3dba23e8fadc360aed75ce363ba185c49794, 2023-08-09T22:20:33.924Z) OS version: Darwin arm64 23.1.0 Modes:

System Info

|Item|Value| |---|---| |CPUs|Apple M1 (8 x 24)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled| |Load (avg)|2, 2, 2| |Memory (System)|16.00GB (0.05GB free)| |Process Argv|.| |Screen Reader|no| |VM|0%|

[mikes-gh]

Thank you for posting I have exactly the same issue and thought I was the only one. I am also using latest bits on Apple silicon.

[dibarbet]

So currently this is by design. Originally we reported info/suggestion diagnostics using VSCode's 'Info' level diagnostic. This turns them into blue squiggles and they show up in the problems window.

However, we got a number of complaints about it being too noisy, so we ended up changing the server to report them under VSCode's 'Hint' severity. This renders them as 3 dots in the editor, but does not show them in the problems window. See https://github.com/dotnet/roslyn/pull/69403

Unfortunately we don't have any more control over the rendering in VSCode, those are our two choices. One potential option is to add a setting to configure how to display info/suggestion diagnostics (cc @mavasani).

Going to leave this issue open for now to collect feedback - if the current behavior is bothersome, leave an upvote.

[mikes-gh]

I disagree with this decision. Using the problems window allows navigation to the file to fix the INFO. I can also filter to see a certain INFO to work on formatting for example. How do I do that now? If other people find it too noisy, they can turn off the INFO in .editorconfig or better still fix their code. I don't have an option to show INFOs in problems pane, however. Also consider I don't have an option to upgrade these INFOS to WARNINGS if the project has <TreatWarningsAsErrors>.

[mikes-gh]

Me again. I don't think changing the classification of the diagnostic I have specified in my .editorconfig (or the defaults) because it's easier to achieve the UI you want is the correct way to solve this.

[daleeidd]

we got a number of complaints about it being too noisy

Makes sense and I agree with the sentiment.

One potential option is to add a setting to configure how to display info/suggestion diagnostics

Sounds ideal.

[mikes-gh]

"Too noisy" is subjective so a setting would be great in vscode . Reclassifying configured diagnostics as a workaround and losing problem pane for INFOS makes the product less functional. VS doesn't suffer this.

[mikes-gh]

@dibarbet Please could you label this O# parity since the only way to get the functionality back is to revert to Omnisharp? 🙏

[mikes-gh]

Any news on this. I am really missing suggestions in problems age. The triple dot hint inline is easy to miss especially if you have a naming issue with underscore.

Take the following example where _Paused should be _paused

In addition, there is no way to navigate of filter between suggestions.

[rjgotten]

@dibarbet However, we got a number of complaints about it being too noisy, so we ended up changing the server to report them under VSCode's 'Hint' severity.

The correct way for this to have been fixed, would have been to connect the Silent diagnostic level to VSCode's 'Hint' severity, if this wasn't already done so, and to then tell those complaining users to properly configure their code analysis rules to map the rules that they're offended by to the Silent level via e.g. .editorconfig.

A major usage of configuring rulesets with rules at the informational level is so you can have a central overview of rules you'd like to see fixed, but that don't have to be fixed before finishing up a unit of work and merging back a pull request. You can then configure a build server that gates completion of a PR to build with 'treat warnings as errors' and prevent completion of work where certain violations must be fixed first, without those same violations leading to compiler errors during development on the developer's local machine. (Where 'treat warnings as errors' can simply be left off.)

Right now-- the option of having that granular partitioning went entirely out the window. Just up and removing reporting on the informational level entirely just like that, is asinine -- and it should be reverted toute-de-suite.