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

Fix KDocReferencesNonPublicProperty false positive #5534

Merged
merged 1 commit into from
Dec 12, 2022
Merged

Fix KDocReferencesNonPublicProperty false positive #5534

merged 1 commit into from
Dec 12, 2022

Conversation

dzirbel
Copy link
Contributor

@dzirbel dzirbel commented Nov 15, 2022

KDocReferencesNonPublicProperty has a common false-positive where there is a name overlap with a public and non-public property (e.g. a local variable). This should not be reported as an issue since the kdoc is referencing the public field.

To fix this, we need to add awareness of the public properties and filter out name overlaps when checking if non-public properties are being referenced in the kdoc. This also includes properties declared as constructor parameters.

Also add a test that constructor parameters are allowed to be referenced in the class kdoc even when they are private fields.

KDocReferencesNonPublicProperty has a common false-positive where there is a name overlap with a public and non-public property (e.g. a local variable). This should not be reported as an issue since the kdoc is referencing the public field.

To fix this, we need to add awareness of the public properties and filter out name overlaps when checking if non-public properties are being referenced in the kdoc. This also includes properties declared as constructor parameters.

Also add a test that constructor parameters are allowed to be referenced in the class kdoc even when they are private fields.
@dzirbel
Copy link
Contributor Author

dzirbel commented Nov 15, 2022

An alternative I'm only realizing now is to try to just process the class-level properties and skip local variables entirely (if this is possible). That sounds cleaner but would slightly weaken the rule since it would not warn for references to local variables - but that seems like more of an edge case that the rule probably wasn't intended to cover in the first place.

Copy link
Member

@BraisGabin BraisGabin left a comment

Choose a reason for hiding this comment

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

LGTM thanks!

@BraisGabin BraisGabin added this to the 1.23.0 milestone Dec 3, 2022

val comment = klass.docComment?.text ?: return

klass.primaryConstructor?.accept(
Copy link
Member

Choose a reason for hiding this comment

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

Do you know why we couldn't use klass.primaryConstructor?.valueParameters?

Copy link
Member

Choose a reason for hiding this comment

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

Agreed that this PR is improving by fixing known edge cases. This can be done as a follow-up (Today I learned that [param] syntax does not work if param is only a parameter not property.)

@chao2zhang chao2zhang merged commit f5f3276 into detekt:main Dec 12, 2022
@dzirbel dzirbel deleted the kdocProperty branch September 23, 2023 05:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants