Skip to content
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

[LSG] Logging Source Generator fails to detect event name uniqueness within a class scope #64667

Closed
Tracked by #77390 ...
maryamariyan opened this issue Feb 2, 2022 · 6 comments · Fixed by #80460
Closed
Tracked by #77390 ...
Labels
api-approved API was approved in API review, it can be implemented area-Extensions-Logging blocking Marks issues that we want to fast track in order to unblock other important work
Milestone

Comments

@maryamariyan
Copy link
Member

maryamariyan commented Feb 2, 2022

As per design logging source generator provides a warning diagnostic when event ID is not unique within the scope of a class between log methods using LoggerMessageAttribute. It should also be able to set diagnostic message and detect when event name is being reused in the same scope.

Proposal

The proposed diagnostic descriptor would be:

public static DiagnosticDescriptor ShouldntReuseEventNames { get; } = new DiagnosticDescriptor(
    id: "SYSLIB1025",
    title: new LocalizableResourceString(nameof(SR.ShouldntReuseEventNamesTitle), SR.ResourceManager, typeof(FxResources.Microsoft.Extensions.Logging.Generators.SR)),
    messageFormat: new LocalizableResourceString(nameof(SR.ShouldntReuseEventNamesMessage), SR.ResourceManager, typeof(FxResources.Microsoft.Extensions.Logging.Generators.SR)),
    category: "LoggingGenerator",
    DiagnosticSeverity.Warning,
    isEnabledByDefault: true);

With the following title:

Multiple logging methods should not use the same event name within a class

And the following message format:

Multiple logging methods are using event name {0} in class {1}

Code Sample

IReadOnlyList<Diagnostic> diagnostics = await RunGenerator(@"
    partial class MyClass
    {
        [LoggerMessage(EventId = 0, EventName = ""MyEvent"", Level = LogLevel.Debug, Message = ""M1"")]
        static partial void M1(ILogger logger);

        [LoggerMessage(EventId = 1, EventName = ""MyEvent"", Level = LogLevel.Debug, Message = ""M1"")]
        static partial void M2(ILogger logger);
    }
");
@dotnet-issue-labeler dotnet-issue-labeler bot added area-Extensions-Logging untriaged New issue has not been triaged by the area owner labels Feb 2, 2022
@ghost
Copy link

ghost commented Feb 2, 2022

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

Issue Details

As per design logging source generator provides a warning diagnostic when event ID is not unique within the scope of a class between log methods using LoggerMessageAttribute. It should also be able to set diagnostic message and detect when event name is being reused in the same scope.

Author: maryamariyan
Assignees: -
Labels:

untriaged, area-Extensions-Logging

Milestone: -

@maryamariyan maryamariyan removed the untriaged New issue has not been triaged by the area owner label Feb 2, 2022
@maryamariyan maryamariyan added this to the 7.0.0 milestone Feb 2, 2022
@eerhardt eerhardt modified the milestones: 7.0.0, Future Jul 14, 2022
@maryamariyan maryamariyan modified the milestones: Future, 8.0.0 Sep 28, 2022
@maryamariyan maryamariyan changed the title Logging Source Generator fails to detect event name uniqueness within a class scope [LSG] Logging Source Generator fails to detect event name uniqueness within a class scope Nov 16, 2022
@allantargino
Copy link
Contributor

Hi @maryamariyan/@tarekgh, I'd like to take this one :)

@allantargino
Copy link
Contributor

allantargino commented Jan 7, 2023

Proposal

The proposed diagnostic descriptor would be:

public static DiagnosticDescriptor ShouldntReuseEventNames { get; } = new DiagnosticDescriptor(
    id: "SYSLIB1025",
    title: new LocalizableResourceString(nameof(SR.ShouldntReuseEventNamesTitle), SR.ResourceManager, typeof(FxResources.Microsoft.Extensions.Logging.Generators.SR)),
    messageFormat: new LocalizableResourceString(nameof(SR.ShouldntReuseEventNamesMessage), SR.ResourceManager, typeof(FxResources.Microsoft.Extensions.Logging.Generators.SR)),
    category: "LoggingGenerator",
    DiagnosticSeverity.Warning,
    isEnabledByDefault: true);

With the following title:

Multiple logging methods should not use the same event name within a class

And the following message format:

Multiple logging methods are using event name {0} in class {1}

Code Sample

IReadOnlyList<Diagnostic> diagnostics = await RunGenerator(@"
    partial class MyClass
    {
        [LoggerMessage(EventId = 0, EventName = ""MyEvent"", Level = LogLevel.Debug, Message = ""M1"")]
        static partial void M1(ILogger logger);

        [LoggerMessage(EventId = 1, EventName = ""MyEvent"", Level = LogLevel.Debug, Message = ""M1"")]
        static partial void M2(ILogger logger);
    }
");

@tarekgh
Copy link
Member

tarekgh commented Jan 7, 2023

@allantargino thanks for the proposal. I'll update the issue subject with it and we can take it to the design review.

@tarekgh tarekgh added blocking Marks issues that we want to fast track in order to unblock other important work api-ready-for-review API is ready for review, it is NOT ready for implementation labels Jan 7, 2023
@allantargino
Copy link
Contributor

Thanks @tarekgh. Again, sorry - I did a mistake when copying the code sample from the tests. Would you please update it again? I really appreciated!

@terrajobst terrajobst added api-approved API was approved in API review, it can be implemented and removed api-ready-for-review API is ready for review, it is NOT ready for implementation labels Jan 10, 2023
@terrajobst
Copy link
Member

terrajobst commented Jan 10, 2023

Video

Looks good as proposed

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jan 10, 2023
allantargino added a commit to allantargino/dotnet-runtime that referenced this issue Jan 11, 2023
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jan 11, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Feb 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-approved API was approved in API review, it can be implemented area-Extensions-Logging blocking Marks issues that we want to fast track in order to unblock other important work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants