shuebner / ClosedTypeHierarchyDiagnosticSuppressor

Suppresses exhaustiveness warnings for switching (switch statement or expression) on closed type hierarchies
MIT License
44 stars 3 forks source link

Can't get the suppression to work in Rider #6

Closed thomaseyde closed 1 year ago

thomaseyde commented 1 year ago

I can't figure out how to get this suppression to work in Rider. Is it so that it will not work at all because Rider doesn't support analyser suppressions?

I installed the NuGet package. That by itself didn't do anything, as expected. I use records. Modifying .editorconfig to suppress records, also did nothing.

Test code as follows:

abstract record Command
{
    public sealed record Create : Command;

    public sealed record Update : Command;
}

public class UnitTest1
{
    [Fact]
    public void Test1()
    {
        Command command = new Command.Create();

        // NuGet package is installed
        // .editorconfig is modified to suppress on records
        // CS8509 warning still not suppressed
        var action = command switch
        {
            Command.Create c => "Create",
            Command.Update u => "Update",
        };
    }
}

It's a shame, really. Was looking forward to fix this silly compiler problem.

Would it be possible to do this the other way around? To create an analyser with with a custom id, like XX8509 to replace CS8509, and have that to raise a warning when the switch expression doesn't handle all cases on a closed type hierarchy?

shuebner commented 1 year ago

Hi Thomas,

TL;DR: Rider does not support diagnostic suppressors and no-one really seems to care. I will not create a replacement analyzer, because that is A LOT more work. Also note that even in VS your test code would not trigger suppression because your Command record's constructor is not private.

The long version:

unfortunately, it seems that Rider does not support DiagnosticSuppressors. I link to the corresponding issue in the README. Since I created this, it has become apparent that for some reason diagnostic suppressors are not supported by many tools, such as Rider, VS Code through Omnisharp and even Visual Studio for Mac. They are really only supported by Visual Studio for Windows.

So yes, I have thought about the workflow you suggest to disable the three diagnostics altogether and issue new ones instead.

This brings of course the burden of making sure that the new analyzer is at least as good as the one it aims to replace. This means constant maintenance in the face of new language features etc..

With the current approach the suppressor does not have to worry about any of that because it just does nothing when it is not sure what to do. It will never make anything worse. On the contrary, the suppressor automatically benefits from improvements made to the built-in analyzers.

The only effective approach I can think of would be to include the built-in analyzers in the replacement analyzer, run them and then only report the diagnostics that would not be suppressed. This would have to entail regular updates whenever the built-in analyzers are updated, keeping in sync with their different TFMs etc.. I do not have time atm to explore this option.

There already are analyzers that try to replace the existing exhaustiveness checks, like (https://github.com/sundews/Sundew.DiscriminatedUnions) and probably others. Last I checked, they did lack important features though, like proper NRT support, which is why I started this project in the first place.

I hope you can find or create something that fits your needs :-)

shuebner commented 1 year ago

Closed due to inactivity