Support [CallerMemberName] and similar parameters in a [LoggerMessage]

[RowlandBanks]

Description

As a developer, I use Source-generated logging to permit high-performance logging.

The specific logging provider I use supports structured logging, and it is useful to me to know where in my program a particular logging message was emitted.

In order to accomplish that, I can use the [CallerMemberName], [CallerFilePath] and [CallerLineNumber] attributes to automatically emit the caller information into my log messages, like so:

[LoggerMessage(LogLevel.Information, Message = "Person created: {Name}")]
public static partial void LogPersonCreated(
    this ILogger logger,
    string Name,
    [CallerMemberName] string? Method = null,
    [CallerLineNumber] int LineNumber = 0,
    [CallerFilePath] string? File = null);

Output (when using AddJsonConsole for logging)

{
  "EventId": 1358002524,
  "LogLevel": "Information",
  "Category": "ConsoleApp1.PersonService",
  "Message": "Person created: Steve",
  "State":
  {
    "Message": "Person created: Steve",
    "Name": "Steve",
    "Method": "CreatePerson",
    "LineNumber": 24,
    "File": "C:\\src\\ConsoleApp1\\PersonService.cs",
    "{OriginalFormat}": "Person created: {Name}"
  }
}

Problem

Unfortunately, currently this will cause 3 SYSLIB1015 warnings to be emitted:

warning SYSLIB1015: Argument 'Method' is not referenced from the logging message
warning SYSLIB1015: Argument 'LineNumber' is not referenced from the logging message
warning SYSLIB1015: Argument 'File' is not referenced from the logging message

I would like a mechanism to suppress/prevent these warnings. The suppression should be targeted so that only these warnings are supressed/prevented, as SYSLIB1015 is, in general, an extremely useful warning.

Suggested implementation

One approach would be to add an additional attribute to each parameter to indicate to the logging generator that these parameters are intended to be consumed by the logging provider, and so are intentional.

For example, there might be a [ContextInformationAttribute] that is used to suppress this warning, like so:

[LoggerMessage(LogLevel.Information, Message = "Person created: {Name}")]
public static partial void LogPersonCreated(
    this ILogger logger,
    string Name,
    [ContextInformation][CallerMemberName] string? Method = null,
    [ContextInformation][CallerLineNumber] int? LineNumber = null,
    [ContextInformation][CallerFilePath] string? File = null);

This has the advantage that it is a flexible mechanism that could work for any information that is intended to be used only for structured logging (although scopes can, in general, achieve the same aim).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-logging
See info in area-owners.md if you want to be subscribed.

[KalleOlaviNiemitalo]

(although scopes can, in general, achieve the same aim)

AFAICT, logger scopes will not work in buffered logging. dotnet/extensions#5635 (comment)

[tarekgh]

CC @geeknoid

[geeknoid]

Two solutions are possible in the current system:

• Remove the logging message completely. This is the solution we recommend internally. It adds little value and costs real CPU time to produce. Doing so will eliminate the warnings and save you some COGS. Normally, the event ID generated by the code generator includes the name of the logging method, but I'm not seeing that in your output for some reason. When you have the name of the logging method in there, the message text is usually 100% redundant.

• Add a suppression for the specific warning at the point where the logging method is declared. This is logically equivalent to adding the ContextInformation attribute suggested.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.