USP0016 not working in VS Code

[heshuimu]

Bug description

A clear and concise description of what the bug is.

• Version of analyzers assembly: 1.12
• Analyzer rule: USP0016
• Error (exception message, type, and callstack where applicable): N/A

To Reproduce

Steps or code to reproduce the behavior: The following code would not have CS8618 if opened in VS for Mac, but will have errors if opened in VS Code. Because of this I have no way to recreate the issue while debugging with VS for Mac. If there is a way to debug analyzers with VS Code, I'd do a PR.

public class UnityUIController : MonoBehaviour
{
    [Header("Common UI")]
    [SerializeField]
    private GameObject progressDialog;
    [SerializeField]
    private GameObject selectionDialog;
}

If it helps, I'm using this version of Mono for the C# plugin

Mono JIT compiler version 6.12.0.162 (2020-02/2ca650f1f62 Tue Nov 30 10:18:09 EST 2021)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
    TLS:           
    SIGSEGV:       altstack
    Notification:  kqueue
    Architecture:  amd64
    Disabled:      none
    Misc:          softdebug 
    Interpreter:   yes
    LLVM:          yes(610)
    Suspend:       hybrid
    GC:            sgen (concurrent by default)

Expected behavior

No CS8618 warnings

Screenshots

The following shows that some Suppressors do work in VS Code since the support is added.

[sailro]

Are you on the latest VSCode ?

For a long time analyzers were working properly but not suppressors. (it seems to be still the case on the VSCode documentation : https://code.visualstudio.com/docs/other/unity#_enabling-unity-warnings)

We filled an issue regarding this on the OmniSharp repo: https://github.com/OmniSharp/omnisharp-roslyn/issues/1711

[heshuimu]

Hi @sailro, I saw that the support for suppressor was added in a while ago (https://github.com/OmniSharp/omnisharp-roslyn/pull/2182).

From my testing, at least USP0001 and USP0003 is working. I updated the screenshot to reflect more examples of the suppressors at work.

I am using everything latest. I'm on C# plugin 1.24.1 and VS Code 1.65.2. My Mono should also be latest; the version info is in the top post.

[heshuimu]

I managed to get debugging working by building a debug version of the analyzer DLL and attach a mono debugger to OmniSharp. From my observation, breakpoints placed at the start of NullableReferenceTypesSuppressor.ReportSuppressions are never hit, while breakpoints in other suppressors do get hit. It's definitely a surprise to me.

SupportedSuppressions of that suppressor do get called on OmniSharp startup, so it is definitely loaded in.

Can I suspect this is an OmniSharp issue?

[sailro]

Ah very interesting, thank you for investigating this.

Indeed if our SupportedSuppressions property is called, we know for sure we are correctly loaded.

Could it be related to a custom .editorconfig file entry somewhere? Or perhaps given the severity level (like suggestion), Omnisharp is enabling/showing the CS8618 analyzer but not passing suppressed entries to our suppressor ?

perhaps you could try the following:

[*.cs]
dotnet_diagnostic.CS8618.severity = warning

@jbevain any idea ?

[heshuimu]

Could it be related to a custom .editorconfig file entry somewhere? Or perhaps given the severity level (like suggestion), Omnisharp is enabling/showing the CS8618 analyzer but not passing suppressed entries to our suppressor ?

I do have .editorconfig in my project, but there is nothing specific to modify the severity of CS8618. In fact, I got rid of those configs as it was mainly for blocking out false positives of other analyzers that I no longer use, and the issue still persists. I don't have a global copy of .editorconfig either.

[sailro]

Hi @filipw, I think the thread above is interesting regarding diagnostic suppressors and omnisharp-vscode / omnisharp-roslyn.

To summarize, several suppressors of our package are working correctly, but for this one, we can see that it is correctly loaded (@heshuimu was able to debug the call to the initialization step), but never called afterwards when a CS8618 diagnostic is found.

We only repro under vscode/omnisharp and it is working correctly with VS, VSMac and our test suite using Roslyn directly.

Do you have any idea that we could explore to try to solve this ? Thanks!

[sailro]

@heshuimu we were able to create a minimal repro without Unity. In the end the issue seems to be on the Roslyn side (compiler infrastructure).

The fix: https://github.com/dotnet/roslyn/pull/68270