-
Notifications
You must be signed in to change notification settings - Fork 510
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
Make SA1600 trigger on undocumented record primary ctor parameters #3783
base: master
Are you sure you want to change the base?
Make SA1600 trigger on undocumented record primary ctor parameters #3783
Conversation
Add analysis of XML <param> tags to SA1600 so that it is raised on record primary constructor parameters.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #3783 +/- ##
==========================================
+ Coverage 95.03% 97.43% +2.40%
==========================================
Files 919 921 +2
Lines 109458 109774 +316
Branches 3306 3316 +10
==========================================
+ Hits 104024 106960 +2936
+ Misses 4455 1838 -2617
+ Partials 979 976 -3 |
You can add a virtual method in the test class to handle different behavior in different Roslyn versions. |
Sorry, but I didn't understand what you meant. Note that the verifier class contains a number of overloads of VerifyCSharpDiagnosticAsync, with different parameters, with and without language version. Why did you need to add this method? |
I added it to pass in the xml files so that I could test the included documentation case, following the example of SA1611. Is there a different way to test this? |
Sorry! I completely misread your original comment and that's why I didn't understand it. I focused on your mention of LanguageVersion and got confused. Never mind. Adding it in that file seems fine to me. It can be moved later on if needed. I will try to look at this again tonight, unless you have already received another response by then. |
|
||
internal partial struct RecordDeclarationSyntaxWrapper : ISyntaxWrapper<TypeDeclarationSyntax> | ||
{ | ||
public static implicit operator RecordDeclarationSyntaxWrapper(TypeDeclarationSyntax node) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This corresponds to a conversion from a base type to a sub type. Adding an implicit conversion operator for that is not a good thing in my book.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point, I am happy to make it an explicit operator. With the way it is being used I could also do something like:
bool RecordDeclarationSyntaxWrapper.TryWrap(TypeDeclarationSyntax node, out RecordDeclarationSyntaxWrapper result)
similar to int.TryParse
and friends. I'm not sure if that's a bit out there though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear: The explicit conversion operator already exists, so you can just remove this file and add a cast where you get an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, understood. Removed this file and used the explicit operator.
|
||
if (includedDocumentation.Nodes().OfType<XElement>().Any(element => element.Name == XmlCommentHelper.InheritdocXmlTag)) | ||
{ | ||
hasInheritdoc = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is not executed in tests. I have no idea why it was needed where you copied it from :-), but maybe you can try to find out to see if more tests should be added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It handles the case where your XML comment includes an XML file, which itself specifies an <inheritdoc />
.
I've added a test that should cover this case.
} | ||
} | ||
|
||
private static class EmptyArray<T> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would move it to the Helpers folder so it can be used in other places as well if needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a bit of refactoring and was no longer using this, so I've removed it
I think it's sufficiently complex to unify if it can be done without too much work, but I would wait for @sharwell's opinion on that. |
Just a quick question: is there any issue with me responding to review feedback now, knowing my pipelines will fail before the double diagnostic problem is resolved? I am a bit clueless there and @sharwell kindly offered to look into it in #3780. I'm not familiar with Azure Pipelines and am unsure if you guys are being charged per run or anything like that 😅 |
I think that this will do it:
I just checked your failing tests and it looks to me like this should work. So instead of adding the expected diagnostics inside the test method, extract that code to a method per test ( |
Ah, ok, thanks @bjornhellander. I wasn't sure if it was a case of needing to fix the analyzer or the tests, but it sounds like this is Roslyn behaviour so updating the tests is probably all that we can do. I will make those changes when I next take a look at this and hopefully have something ready for review. |
Regarding unifying For now, I've added an extension method to I also felt this was a bit better than pasting into a private method; a 'domain model' class to represent XML comments that are parsed either from the Roslyn syntax tree or from |
Add analysis of XML
<param>
tags to SA1600 so that it is raised on record primary constructor parameters. Closes #3780.This is in draft as I had a few questions:
this.LanguageVersion
to the verification. I wasn't quite sure how (or if) I should adapt the custom verifier method to accept this.SA1600ElementsMustBeDocumented.GetDocumentedParameters
is more or less entirely copied fromElementDocumentationBase.HandleDeclaration
. Would it be worth extracting this into a common helper, or are they sufficiently unique to leave separate?Edit: I think all 3 items above are fairly resolved, so have moved out of draft.