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

Formatting rules are reported at wrong line (e.g. MaximumLineLength) #1843

Closed
sschuberth opened this issue Aug 23, 2019 · 4 comments
Closed

Comments

@sschuberth
Copy link
Contributor

sschuberth commented Aug 23, 2019

Expected Behavior

I expect MaximumLineLength to be reported at the line it occurred.

Observed Behavior

MaximumLineLength is reported at <correct line> - 2 (in my case).

Steps to Reproduce

Ruleset: comments
Ruleset: complexity
Ruleset: empty-blocks
Ruleset: exceptions
Ruleset: formatting - 5min debt
        MaximumLineLength - [PsiWhiteSpace] at C:\Dev\oss-review-toolkit\scanner\src\funTest\kotlin\storages\PostgresStorageTest.kt:39:65
Ruleset: naming
Ruleset: performance
Ruleset: potential-bugs
Ruleset: style - 5min debt
        MaxLineLength - [createStorage] at C:\Dev\oss-review-toolkit\scanner\src\funTest\kotlin\storages\PostgresStorageTest.kt:41:5

Note that the ktlint-based MaximumLineLength is reported at line 39 (wrong), but the detekt-based MaxLineLength is reported at line 41 (correct) for the same file.

Also, running stand-alone ktlint 0.34.2 correctly reports 41, so the issue is with detekt, not with ktlint.

Context

Might be related to #1688.

Your Environment

@sschuberth
Copy link
Contributor Author

Still present in detekt 1.0.1.

@arturbosch
Copy link
Member

All detekt-formatting rules are reported with slightly wrong positions - #2120.

@arturbosch arturbosch changed the title MaximumLineLength reported at wrong line Formatting rules are reported at wrong line (e.g. MaximumLineLength) Nov 23, 2019
@sschuberth
Copy link
Contributor Author

Oh! Should detekt then maybe say "approximate line X" for these rules to avoid confusion?

@arturbosch
Copy link
Member

Oh! Should detekt then maybe say "approximate line X" for these rules to avoid confusion?

Hm, I think as most users use the autoCorrect for this it's not that big of an issue.
However we need to debug why we report them wrongly.
For detekt-rules we use the kotlin compilers method to transform line endings. KtLint uses own method to do this. For detekt-formatting we combine both methods which I think is the reason for this.

sschuberth added a commit to sschuberth/detekt that referenced this issue Apr 14, 2020
This is the offset expected by the calculateLineColByOffset() function
copied from KtLint.

Fixes detekt#1843.
Bugs and False Positives automation moved this from Next to Done Apr 14, 2020
@arturbosch arturbosch added this to the 1.8.0 milestone Apr 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

3 participants