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

Fixes false positive of trailing whitespaces in kdoc #6370

Closed
wants to merge 2 commits into from

Conversation

atulgpt
Copy link
Contributor

@atulgpt atulgpt commented Aug 5, 2023

Fixes #5713

@codecov
Copy link

codecov bot commented Aug 5, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (bf0e3f6) 85.18% compared to head (2087ba4) 85.18%.

Additional details and impacted files
@@            Coverage Diff            @@
##               main    #6370   +/-   ##
=========================================
  Coverage     85.18%   85.18%           
- Complexity     4061     4067    +6     
=========================================
  Files           565      565           
  Lines         13321    13323    +2     
  Branches       2401     2401           
=========================================
+ Hits          11347    11349    +2     
  Misses          773      773           
  Partials       1201     1201           
Files Coverage Δ
...rturbosch/detekt/rules/style/TrailingWhitespace.kt 97.22% <66.66%> (+0.16%) ⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@BraisGabin BraisGabin enabled auto-merge (squash) August 6, 2023 09:11
@BraisGabin
Copy link
Member

I'm not 100% sure about this one. Dokka doesn't support this. So they are really trailing spaces with no meaning. I would vote to close pr and issue until Dokka decides to support it. Otherwise I feel that we are adding false negatives more than adding a real feature.

@atulgpt
Copy link
Contributor Author

atulgpt commented Aug 6, 2023

I'm not 100% sure about this one. Dokka doesn't support this. So they are really trailing spaces with no meaning. I would vote to close pr and issue until Dokka decides to support it. Otherwise I feel that we are adding false negatives more than adding a real feature.

Hi, @BraisGabin I don't have a strong opinion on this issue. It's just that it is marked as a false positive in the bug tracker that's why I picked this issue. I am okay with any closing this issue as well

@BraisGabin
Copy link
Member

I'm adding @TWiStErRob as reviewer here becuase it is his issue. I don't have a strong opinion here to be honest.

Copy link
Member

@TWiStErRob TWiStErRob left a comment

Choose a reason for hiding this comment

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

I agree with @BraisGabin, as I said in #5713 (comment).

I re-read the context, and while it's technically correct to support this, if KDoc doesn't do it, then people (like I did) will have a false sense that those spaces will do something.

Based on this I vote to close the PR; with the option to repurpose it in the future if/when feature is added, this is why I reviewed it. Until then, I think maybe opening a PR to update our docs and explain why those spaces are being flagged in "standard markdown" is the best way forward. That other PR could close the issue.

@@ -51,6 +52,15 @@ class TrailingWhitespace(config: Config = Config.empty) : Rule(config) {
}
}

private fun PsiElement.isKdocTrailingSpaces(trailingWhitespaces: Int): Boolean {
return this.parent is KDocSection && trailingWhitespaces == 2
Copy link
Member

Choose a reason for hiding this comment

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

Markdown spec says 2 or more.

Copy link
Member

Choose a reason for hiding this comment

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

Than I think that the first two are correct but the others are trailing spaces.

Copy link
Member

Choose a reason for hiding this comment

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

Huh, makes sense to interpret it that way. If we go with "report an error as we do it now but we change the message", it can still be just >=2 because any number is unsupported right now.

@@ -51,6 +52,15 @@ class TrailingWhitespace(config: Config = Config.empty) : Rule(config) {
}
}

private fun PsiElement.isKdocTrailingSpaces(trailingWhitespaces: Int): Boolean {
return this.parent is KDocSection && trailingWhitespaces == 2
Copy link
Member

Choose a reason for hiding this comment

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

Are nested list items still parented by KDocSection: nested list items?

return this.parent is KDocSection && trailingWhitespaces == 2
}

private fun PsiElement.shouldReport(trailingWhitespacesCount: Int): Boolean {
Copy link
Member

Choose a reason for hiding this comment

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

I would flip this to simplify:

Suggested change
private fun PsiElement.shouldReport(trailingWhitespacesCount: Int): Boolean {
private fun PsiElement.isValid(trailingWhitespacesCount: Int): Boolean {

fun `reports a excessive trailing spaces in kdoc`() {
val code = """
/**
* a
Copy link
Member

Choose a reason for hiding this comment

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

These tests look really funny without visible spaces, would

Suggested change
* a
* a$space$space$space

be a stretch?

Copy link
Member

Choose a reason for hiding this comment

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

This could also prevent future bulk clean-up of trailing spaces inside string literals.

fun `reports a excessive trailing spaces in kdoc`() {
val code = """
/**
* a
Copy link
Member

Choose a reason for hiding this comment

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

Align stars to mimic real(er) code.

@BraisGabin
Copy link
Member

BraisGabin commented Aug 11, 2023

Until then, I think maybe opening a PR to update our docs and explain why those spaces are being flagged in "standard markdown" is the best way forward. That other PR could close the issue.

And what if we report an error as we do it now but we change the message? We could say that this feature of markdown is not supported and link to the open issue.

Even so, I don't see too much value here. To me we could directly close this PR and the issues directly. I would leave that decission to @atulgpt as he is the one doing the heavy lifting here.

@TWiStErRob
Copy link
Member

And what if we report an error as we do it now but we change the message? We could say that this feature of markdown is not supported and link to the open issue.

I like that!

@atulgpt
Copy link
Contributor Author

atulgpt commented Aug 16, 2023

Until then, I think maybe opening a PR to update our docs and explain why those spaces are being flagged in "standard markdown" is the best way forward. That other PR could close the issue.

And what if we report an error as we do it now but we change the message? We could say that this feature of markdown is not supported and link to the open issue.

Even so, I don't see too much value here. To me we could directly close this PR and the issues directly. I would leave that decission to @atulgpt as he is the one doing the heavy lifting here.

Hi @BraisGabin, @TWiStErRob I will update the PR incorporating your reviews

@cortinico cortinico modified the milestones: 1.23.2, 2.0.0 Aug 19, 2023
@cortinico cortinico added the pick request Marker for PRs that should be ported to the 1.0 release branch label Aug 19, 2023
@BraisGabin
Copy link
Member

@detekt/maintainers We need to take a decission here. A go or a not go to this PR. To me this is a not go and just close the issue as "work as expected". If Dokka fix the issue I would be more than happy to add this but now until that moment.

@TWiStErRob
Copy link
Member

Vote to close, but open another with a doc update to the rule (1 sentence) to explain what's happening.

[or maybe detect the case, and provide a clear edge case error message, probably not worth the effort/maintenance]

@BraisGabin BraisGabin closed this Nov 10, 2023
@schalkms
Copy link
Member

Same - good decision!

@atulgpt
Copy link
Contributor Author

atulgpt commented Nov 11, 2023

Yup makes sense closing the issue.. o/w ROI was not justified

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pick request Marker for PRs that should be ported to the 1.0 release branch rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TrailingWhitespace false positive on KDoc line wraps
6 participants