Fixed LoggerMessageGenerator message escaping.

[John-Leitch]

This PR addresses bug #123786 by escaping all non-printable characters (< 0x20) in the emitted message. \r and \n are emitted using the same escape sequence, while other non-printable characters are emitted as hex escape sequences e.g. \x00. Escaping of \ is also addressed. Finally, an additional test was added to cover these behaviors.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Fixes LoggerMessageGenerator emitting malformed C# string literals by escaping backslashes and all non-printable characters (< 0x20) when generating source, and adds a regression test covering these escaping scenarios.

Changes:

• Update the emitter to escape \ and all control characters (< 0x20) using \xNN (while keeping \r/\n as named escapes).
• Add a new theory test validating the generated source is syntactically valid and contains the expected escaped message literal.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/libraries/Microsoft.Extensions.Logging.Abstractions/gen/LoggerMessageGenerator.Emitter.cs	Extends message escaping to include backslashes and all control characters so generated string literals remain well-formed.
src/libraries/Microsoft.Extensions.Logging.Abstractions/tests/Microsoft.Extensions.Logging.Generators.Tests/LoggerMessageGeneratorEmitterTests.cs	Adds a theory-based regression test for message escaping (backslash, quotes, CR/LF, and \xNN escapes).

[KalleOlaviNiemitalo]

If this outputs e.g. \x12 and the next character happens to be 3, which is copied as is, then the result is \x123, which C# parses as the character U+0123 LATIN SMALL LETTER G WITH CEDILLA.

That risk could be avoided by using "\\u{0:x4}" instead, as \u always consumes exactly 4 hexadecimal digits.