ESLint style single line ignore and lightbulb improvements

[johnnyreilly]

The actual issue that I had in #60620 I now consider solved. (A better way of expressing it might be to say that it wasn't an issue; I just didn't understand correctly 😅)

I've got some developer experience feedback that has occurred to me, as a consequence of writing a blog post that talks about linting in C# as compared to JS/TS with ESLint. Essentially things that the JS/TS ecosystem has that are quite nice that dotnet does not.

I love the lightbulb 💡. When I'm developing, I love the auto fixes and suggestions that it provides.

I don't want to act upon each lint diagnostic. I may just want to ignore a particular one. This is made very easy in the JavaScript ecosystem for two reasons:

1. It's a one liner with ESLint - I can deactivate linting for a single line with // eslint-disable-next-line.

2. ESLint has a VS Code extension which for lints it will present a lightbulb 💡. And one of the options is "ignore the line" which will apply a // eslint-disable-next-line to do just that.

It would be awesome if a similar mechanisms existed in dotnet.

Single line ignore

Obviously I can ignore single lines in C#, but it takes me 2 lines of code to achieve it; like so:

#pragma warning disable IDE0052
    private readonly ILogger<WeatherForecastController> _logger;
#pragma warning restore IDE0052

What if instead, something like this existed:

#pragma warning disable-line IDE0052
    private readonly ILogger<WeatherForecastController> _logger;

Which disabled a single line of linting

Lightbulb

Imagine if the lightbulb with the C# extension offered the option to ignore a lint; just as the ESLint menu does. Quite the timesaver.

I'm not too sure where this feedback should go, but I thought I'd share it here to start with. What do people think? And more than that, is this the right place to discuss this?

[Youssef1313]

This is a language change. Not something Roslyn can do directly, I think. It should start as a discussion in dotnet/csharplang

[jinujoseph]

@sharwell

[sharwell]

Duplicate of dotnet/csharplang#1070

[sharwell]

Note that the light bulb already provides the option to suppress a diagnostic:

[johnnyreilly]

Hi @sharwell - I don't see that option in the lightbulb for VS Code - I think that may be a visual studio only option.

[johnnyreilly]

This is what we see in VS Code.

[CyrusNajmabadi]

@333fred for feedback on vscode.

[Youssef1313]

@CyrusNajmabadi

roslyn/src/Features/CSharp/Portable/CodeFixes/Suppression/CSharpSuppressionCodeFixProvider.cs

Lines 26 to 27 in e162905

	[ExportConfigurationFixProvider(PredefinedConfigurationFixProviderNames.Suppression, LanguageNames.CSharp), Shared]
	internal class CSharpSuppressionCodeFixProvider : AbstractSuppressionCodeFixProvider

This is the only codefix that doesn't have ExportCodeFixProvider and doesn't inherit CodeFixProvider (AbstractSuppressionCodeFixProvider only implements an IConfigurationFixProvider interface).

It seems there is a wrapper CodeFixProvider:

roslyn/src/Features/Core/Portable/CodeFixes/Suppression/WrapperCodeFixProvider.cs

Line 19 in e162905

public WrapperCodeFixProvider(IConfigurationFixProvider suppressionFixProvider, IEnumerable<string> diagnosticIds)

But it also doesn't have the attribute (and its constructor is not parameterless).

Things around this CodeFixProvider is special cased here:

roslyn/src/Features/LanguageServer/Protocol/Features/CodeFixes/CodeFixService.cs

Lines 679 to 696 in e162905

	/// <summary> Looks explicitly for an <see cref="AbstractSuppressionCodeFixProvider"/>.</summary>
	public CodeFixProvider? GetSuppressionFixer(string language, IEnumerable<string> diagnosticIds)
	{
	if (!_configurationProvidersMap.TryGetValue(language, out var lazyConfigurationProviders) ||
	lazyConfigurationProviders.Value.IsDefault)
	{
	return null;
	}
	// Explicitly looks for an AbstractSuppressionCodeFixProvider
	var fixer = lazyConfigurationProviders.Value.OfType<AbstractSuppressionCodeFixProvider>().FirstOrDefault();
	if (fixer == null)
	{
	return null;
	}
	return new WrapperCodeFixProvider(fixer, diagnosticIds);
	}