`LoggerMessageGenerator` emits malformed strings.

[John-Leitch]

Description

The LoggerMessageGenerator class does not properly handle escaping, sometimes emitting malformed strings that do not compile.

Reproduction Steps

The following program demonstrates the issue:

using Microsoft.Extensions.Logging;

namespace LoggerMessageEscapeRepro;

public static partial class LoggerMessageTest
{
    [LoggerMessage(
        EventId = 1,
        Level = LogLevel.Information,
        Message = "Foo \\ bar: {foo}")]
    static partial void Test(ILogger logger, string foo);
}

internal class Program
{
    static void Main(string[] args)
    {
        var logger = new LoggerFactory().CreateLogger<Program>();
        Console.WriteLine("Hello, World!");
    }
}

Expected behavior

The following field is expected in the generated source:

[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Extensions.Logging.Generators", "10.0.13.7005")]
private static readonly global::System.Action<global::Microsoft.Extensions.Logging.ILogger, global::System.String, global::System.Exception?> __TestCallback =
    global::Microsoft.Extensions.Logging.LoggerMessage.Define<global::System.String>(global::Microsoft.Extensions.Logging.LogLevel.Information, new global::Microsoft.Extensions.Logging.EventId(1, nameof(Test)), "Foo \\ bar: {foo}", new global::Microsoft.Extensions.Logging.LogDefineOptions() { SkipEnabledCheck = true }); 

Actual behavior

The following field is what is actually emitted (note the invalid escape sequence):

[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Extensions.Logging.Generators", "10.0.13.7005")]
private static readonly global::System.Action<global::Microsoft.Extensions.Logging.ILogger, global::System.String, global::System.Exception?> __TestCallback =
    global::Microsoft.Extensions.Logging.LoggerMessage.Define<global::System.String>(global::Microsoft.Extensions.Logging.LogLevel.Information, new global::Microsoft.Extensions.Logging.EventId(1, nameof(Test)), "Foo \ bar: {foo}", new global::Microsoft.Extensions.Logging.LogDefineOptions() { SkipEnabledCheck = true }); 

Regression?

No response

Known Workarounds

Double escaping works in at least some cases, but this is not an acceptable solution.

Configuration

No response

Other information

No response

[dotnet-policy-service]

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

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• LoggerMessageAttribute generated source does not respect escaped characters and does not compile #56203

[tarekgh]

isn't similar issue like #121386? I think we should be careful if we try to handle the escaping ourselves. Usually, we ask the user to write the corrected escaping in the message string.

[John-Leitch]

That's effectively the same issue, and I believe my PR will address it. Is expecting the user to double escape really the right approach? Taking a step back, I would argue there should be no circumstance where a source generator emits syntactically incorrect code based on input that is itself syntactically correct.

[cincuranet]

@tarekgh Yes, it it similar. But it is not about providing correct escaping by user, but about us handling "special" characters properly. And I think @John-Leitch's PR fixes that and in fact fixes it quite nicely - not handling \ only, but taking into account any non-printable characters.

[tarekgh]

@John-Leitch Fair enough. I was initially concerned this might cause issues for users who are already manually escaping the message string. However, I realized that we’re already applying the correct escaping in the other extension’s source generator. Fixing this here makes sense for consistency as well. I’ve left a comment on the PR outlining how to address it using the compiler helper method instead.