-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logging Source Generator fails ungracefully with overloaded methods #61814
Comments
Tagging subscribers to this area: @maryamariyan Issue DetailsDescriptionThe LoggerMessage source generator fails when there are overloaded logging methods, even if a unique EventName is defined for both. Reproduction Stepspublic static partial class LoggerMessageGeneration
{
[LoggerMessage(EventId = 1, EventName = "LogInt", Level = LogLevel.Debug, Message = "Test message {One}")]
public static partial void Log1(ILogger logger, int one);
[LoggerMessage(EventId = 2, EventName = "LogBool", Level = LogLevel.Debug, Message = "Test message {Two}")]
public static partial void Log1(ILogger logger, bool two);
} Expected behaviorThe code compiles successfully. If the LoggerMessage generator explicitly does not support logging method overloads, then a diagnostic should be emitted instead. Consider the following code, where an overload is specified without an public static partial class LoggerMessageGeneration
{
[LoggerMessage(EventId = 1, Level = LogLevel.Debug, Message = "Test message {One}")]
public static partial void Log1(ILogger logger, int one);
[LoggerMessage(EventId = 2, Level = LogLevel.Debug, Message = "Test message {Two}")]
public static partial void Log1(ILogger logger, bool two);
} The current behaviour of the source generator is to use the method name as the event name, this would emit logs with different event ids that shared the same event name. Actual behaviorEmits
Regression?No Known WorkaroundsDo not use overloaded methods when using Configuration
Other informationNo response
|
I'd love to take a look at providing a fix for this. |
Calculates and assigns a unique LoggerMethod name as required, and uses this new unique name for generating types in the source generator. This allows using the LoggerMessageAttribute on methods that share the same name but have different method signatures. Fix dotnet#61814
@JakeYallop thanks for your interest. I have a fix prepared already. It also is addressing some other source generator feedback so we would end up having to keep either one of the two. I reviewed your PR in the meantime. |
* Compute unique method names for generated code Calculates and assigns a unique LoggerMethod name as required, and uses this new unique name for generating types in the source generator. This allows using the LoggerMessageAttribute on methods that share the same name but have different method signatures. Fix #61814 * Rename MethodOverloadTestExtensions to OverloadTestExtensions Also resolves other PR feedback, an extra blank line and incorrect use of an implicit type. * Remove un-needed overload tests
Description
The LoggerMessage source generator fails when there are overloaded logging methods.
Reproduction Steps
Expected behavior
The code compiles successfully. If the LoggerMessage generator explicitly does not support logging method overloads, then a diagnostic should be emitted instead.
Consider the following code, where an overload is specified without an
EventName
- should this compile?The current behaviour of the source generator is to use the method name as the event name, this would emit logs with different event ids that share the same event name. If there are logging providers that rely on event names being unique, this could be problematic.
Actual behavior
Emits
Regression?
No
Known Workarounds
Do not use overloaded methods when using
[LoggerMessage]
.Configuration
Other information
No response
The text was updated successfully, but these errors were encountered: