[release/6.0] Fix Logging source generator failures with various syntax

[maryamariyan]

Customer Impact

Presenting 3 customer-reported issues, being blocked from using the Logging Source Generator when using the following use cases below. (Workarounds require customers to significantly change their usage which prevents them from adopting the feature).

---

• Issue Logging Source Generator fails to compile using keyword parameters with @ prefixes #60968 was the most requested by community as part of post-release 6.0 feedback so it would be good to backport it to 6.0:

If a C# keyword is used as a parameter name for a [LoggerMessage] method using the logging source generator prefixed with an @, such as the example below, the application will fail to compile due to the source generator creating invalid C#.

[LoggerMessage(1,LogLevel.Information,"Event: {event}")]publicstaticpartialvoidLogEvent(ILoggerlogger,object@event);

If the @ is included in the template to match the parameter, it will also fail to compile.

---

• Issue Logging Source Generator fails to compile due to CS0246 and CS0265 errors if type for generic constraint is in a different namespace #58550 helps with the logging source generator robustness and to developers wanting to migrate to the new logging approach fixes a variety of use cases having to do with constraints:

For example, as originally reported, the generator fails to compile due to CS0246 and CS0265 errors if type for generic constraint is in a different namespace. There's more constraint-related use cases covered within the PR.

---

• Issue Logging Source Generator fails to compile when in parameter modifier is present #62644 helps with the logging source generator support the in or ref modifier, rather than producing a compile failure with the repro sample seen below:

[LoggerMessage(2,LogLevel.Information,"Foo: {my}")]publicstaticpartialvoidLogSomething1(thisILoggerlogger,inMyReadOnlyStructmy);

Regression

No

Testing

Automated test cases added to cover the missed syntax. Included in the PRs:

• Logging Source Generator - Adds support to @ signed prefixed parameters #64663
• Fixes two logging source gen bugs - when using "in" or "ref" modifier / when dealing with constraints #64593

Risk

Low. Very targeted changes were selected to handle missed syntax.
Test cases were added and more variants to reported repro cases were also explored.

When fixing for generic constrains, we reduced risk by avoiding duplication of constraints/derived types.

The other two fixes (ref/in support and @ prefixed parameter support) only impact use cases for which we are otherwise unsupported and produce ambiguous compilation errors, has also been reviewed by Roslyn members and therefore are clear improvements with low risk.

Packaging impact:

• Requires packaging of Microsoft.Extensions.Logging.Abstractions

Ref pack impact:

Yes, modifies inbox source-generator contained in ASP.NET ref-pack.

[ghost]

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

Issue Details

---

Recently we added a few post 6.0 bug fixes to main branch. This PR is cherry picking the following ones:

• Fixes bad log method generation in certain cases. #64311
• Fixes two logging source gen bugs - when using "in" or "ref" modifier / when dealing with constraints #64593
• Allow use of overloaded methods when using LoggerMessage #64573
• Reduce allocations in code generated by Logging generators (#61162) #62011
• Logging Source Generator - Adds support to @ signed prefixed parameters #64663

Customer Impact

Bugfix in PR #64663 was the most requested by community as part of post release 6.0 feedback so would be good to backport it to 6.0.

Also, the bugfix in PR helps with the logging source generator robustness and to developers wanting to migrate to the new logging approach fixes a variety of use cases having to do with constraints.

Testing

The PRs have combined test use cases with them.

Risk

Author:	maryamariyan
Assignees:	maryamariyan
Labels:	area-Extensions-Logging
Milestone:	-

[maryamariyan]

To make things clear for tactics and servicing, I only am keeping this one release/6.0 PR for logging source generator improvements.

[ericstj]

To make things clear for tactics and servicing, I only am keeping this one release/6.0 PR

Typically this is not preferred. It makes things a bit harder since it becomes an all or nothing decision to take the PR. The commits are also not independently revertible. I think here we can say these are all low risk changes and we kept them together to avoid merge conflicts with each other.

[maryamariyan]

This received tactics approval. I think it should be OK to merge

[ericstj]

Approved over mail

[safern]

Failures are unrelated. We can merge this one (got approval offline).

[snakefoot]

@safern Missing assignment of .NET 6.0 milestone ? (Since merged into dotnet:release/6.0)