CA1801 in Azure Functions where attribute is needed, but parameter is not

[MisinformedDNA]

I'm not sure this a bug, or an odd use case, but I'm interested in workarounds if it's not.

Analyzer package

Microsoft.CodeAnalysis.FxCopAnalyzers

Package Version

v2.9.3 (Latest)

Diagnostic ID

CA1801

Repro steps

1. Create an Azure Function defined as

[FunctionName(nameof(DoSomethingFunction))]
public async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "delete", Route = "something/{id:int}")] HttpRequest _, int id)
{
    // Do something based on `id`
    return new OkResult();
}

Expected behavior

No warning is generated. The parameter has to be there because the attribute needs to be there.

Actual behavior

Warning is generated.

[sharwell]

The recommended approach we're using in dotnet/roslyn for these cases is to assign the unused parameter to a discard within the method:

// Not required by this implementation
_ = someUnusedParameter;

The shapes proposal sounds like it could provide some benefits in this scenario, similar to how interfaces already trigger exclusions for this rule today.

[mavasani]

We have also changed the IDE implementation of unused parameter rule to exclude parameter symbols with discard symbol name: http://source.roslyn.io/#Microsoft.CodeAnalysis.Features/RemoveUnusedParametersAndValues/AbstractRemoveUnusedParametersAndValuesDiagnosticAnalyzer.SymbolStartAnalyzer.cs,226.

                // Ignore special parameter names for methods that need a specific signature.
                // For example, methods used as a delegate in a different type or project.
                // This also serves as a convenient way to suppress instances of unused parameter diagnostic
                // without disabling the diagnostic completely.
                // We ignore parameter names that start with an underscore and are optionally followed by an integer,
                // such as '_', '_1', '_2', etc.

I am going to implement the same for CA1801 and the user can choose between either using a special name OR the approach suggested by @sharwell above.