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

Add support for primary constructors in LoggerMessageGenerator #101660

Merged

Conversation

kimsey0
Copy link
Contributor

@kimsey0 kimsey0 commented Apr 28, 2024

Fixes #91121.

@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Apr 28, 2024
@tarekgh
Copy link
Member

tarekgh commented Apr 28, 2024

@kimsey0 thanks for submitting the PR. I converted it to draft till it is ready for actual review.

@kimsey0
Copy link
Contributor Author

kimsey0 commented Apr 30, 2024

@tarekgh, with the helpful suggestion from Cyrus, I now think this is ready for review. Should I mark it as such or wait for more feedback, perhaps from @eiriktsarpalis? (I don't know when he's back from vacation.)

.Where(ic => ic.DeclaringSyntaxReferences
.Any(ds => ds.GetSyntax() is ClassDeclarationSyntax));

foreach (IMethodSymbol primaryConstructor in primaryConstructors)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this in itself is a great example of why I said you're not going to get lookup right if you do it by yourself. Consider this example; I've created a protected field in the base type with a wider type than the logger parameter in the derived type, and that protected member shadows the primary constructor parameter. Another similar example is this, where I've shadowed the primary constructor parameter with a field directly in the type itself. I'm not opposed to the idea of adding a new LookupSymbols API here to allow SG authors to say "I need to know what names are available when I implement the body of this type", but it's also important to note that available names are by nature impacted by the usings in the file. Let me talk with @AlekseyTs and see if we can come up with any ideas that avoid you having to try and get this correct.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should also test scenarios like this:

class Test(ILogger logger)
{
    private readonly ILogger _logger = logger;
}

and ensure that you're using the right logger for that scenario.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@333fred is it possible to lookup the fields first and then if didn't find any try to look up the primary constructors?

Also, for detecting the primary constructor, should check constructor.Body == null && constructor.ExpressionBody == null?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private readonly ILogger _logger = logger;

good test as we don't support private fields.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@333fred is it possible to lookup the fields first and then if didn't find any try to look up the primary constructors?

Sure, that would be possible. Talking with Aleksey, that's likely the approach you want to take in general. However, I'm going to strongly recommend that you explicitly consider these cases and lay out, in comments and documentation, the exact rules you follow. IE, what happens when a primary constructor parameter is shadowed? What happens when a base type has a protected member that is named differently than the parameter (ie, has an _)? This will make it easier to verify the behavior is what you're expecting, and to handle bugs as by-design or not.

Also, for detecting the primary constructor, should check constructor.Body == null && constructor.ExpressionBody == null?

You only need the check that kimsey0 put in already. It's important to note that you can only detect primary constructors from source, you cannot detect them from metadata.

good test as we don't support private fields.

Wait, what? I'll reiterate that I think you need spell out exactly what the rules are, in comments above the code, so that you can verify the code follows them. I thought I might understand the rules, but clearly I do not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. If both the behavior described above as well as the code implementing it is acceptable to all parties, I think this is ready for review again.

Copy link
Member

@tarekgh tarekgh May 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to review it when I get a chance. PR is not a draft anymore. Thanks for all the help you have provided here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Thanks a lot!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to commit and push the info diagnostic, but just did that. I don't know if there are any guidelines for how exactly these diagnostic messages should be written or how the translation flow goes? (We can also just revert this. I think it's useful, but not necessary.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't have to worry about the translation of the added messages. I am seeing the added diagnostic is useful to catch the concerned case.

@tarekgh
Copy link
Member

tarekgh commented May 23, 2024

@geeknoid @joperezr to be aware about this change if need to update the extensions logging source gen too.

@joperezr
Copy link
Member

Thanks for flagging this @tarekgh! It does seem like it is something we'll want to do in extensions. Logged dotnet/extensions#5178 to track

@tarekgh
Copy link
Member

tarekgh commented May 26, 2024

        Assert.Equal("SYSLIB1026", diagnostics[0].Id);

Please add similar test for the new diagnostic we added.


Refers to: src/libraries/Microsoft.Extensions.Logging.Abstractions/tests/Microsoft.Extensions.Logging.Generators.Tests/LoggerMessageGeneratorParserTests.cs:1115 in 6cf2b2f. [](commit_id = 6cf2b2f, deletion_comment = False)

@tarekgh
Copy link
Member

tarekgh commented May 26, 2024

@kimsey0 I added a few minor comments. I think we should be good to go after addressing these. Thanks!

@kimsey0
Copy link
Contributor Author

kimsey0 commented May 27, 2024

        Assert.Equal("SYSLIB1026", diagnostics[0].Id);

Please add similar test for the new diagnostic we added.

I added assertions that the new diagnostic is reported to the existing test cases with shadowed primary constructor parameters. Would you like any additional tests of this?

Copy link
Member

@tarekgh tarekgh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kimsey0 providing the fix!

@tarekgh tarekgh merged commit 9daa4b4 into dotnet:main May 28, 2024
84 checks passed
@kimsey0 kimsey0 deleted the logger-message-generator-primary-constructors branch May 28, 2024 17:06
@kimsey0
Copy link
Contributor Author

kimsey0 commented May 28, 2024

Thanks a lot for the help, @tarekgh!

Ruihan-Yin pushed a commit to Ruihan-Yin/runtime that referenced this pull request May 30, 2024
…t#101660)

* Add support for primary constructors in LoggerMessageGenerator

* Get the primary constructor parameters types from the constructor symbol instead of from the semantic model

* Prioritize fields over primary constructor parameters and ignore shadowed parameters when finding a logger

* Make checking for primary constructors non-conditional on Roslyn version and simplify project setup

* Reintroduce Roslyn 4.8 test project

* Add info-level diagnostic for logger primary constructor parameters that are shadowed by field

* Update list of diagnostics with new logging message generator diagnostic

* Only add non-logger field names to set of shadowed names

* Add comment explaining the use of the set of shadowed names with an example
@github-actions github-actions bot locked and limited conversation to collaborators Jun 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Extensions-Logging community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LoggerMessage source generator does not work with logger from primary constructor.
6 participants