ionide / ionide/FSharp.Analyzers.SDK

Allow analyzers to require a reason/justification for ignoring

Open
#308 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
F#
Stars
85
Forks
28
Avg merge
1d 8h
Merged PRs (30d)
20

Description

**Is your feature request related to a problem? Please describe.**
I am currently writing an analyzer that reports functions that throw exceptions, which I generally don't want to happen.
In special cases I really do want to throw an exception, but I want to document why it is a special case that requires an exception.
For that reason, I would like to durably document that I have intentionally disabled an analyzer, and why.

**Describe the solution you'd like**
I would like to extend the ignore directive system such that an analyzer can choose to require a reason/justification for disabling it in the comment.
If no reason is provided, the analyzer should then not actually be ignored, and it should maybe give a special error message saying that a reason is required.

**Describe alternatives you've considered**
I have implemented a hack that emulates this directly in my analyzer by actually ignoring a different error code than the one the analyzer actually uses and then manually checking for that ignore directive.
But this is brittle because people could still disable the actual error code, which would defeat this check.

I imagine that other people might also have this problem, so I think a general solution could be worthwhile.

**Additional context**
I am willing to implement this feature if there is support for it.

Contributor guide

Open the contributing guide

Research direction

The issue names no files, tests, or entry points; start by locating the ignore directive system and existing analyzer tests in the SDK. Define how an analyzer opts into required justifications, then verify that an ignore without a reason does not suppress the diagnostic and reports that a reason is required.

Written by the indexing model from the issue text.

Assessment

Tech stack
fsharp
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.