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

[magenta404]

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 dotnet/roslyn#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.

[magenta404]

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.

[marinasundstrom]

I was surprised today when I discovered this. I'm writing an analyzer that reports info diagnostics.