You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During rewrite of tests (#1444) to using the KtLintAssertThat API, I encounted a number of situations in which a rule does seem to contain a bug. Most of them are simple off-by-one mistakes in the offset at which an error is found. Those situations can easily be found by searching for TODO and @Disabled in the unit tests of the KtLint rules.
Examples:
annotationRuleAssertThat(code)
// TODO: Offset and message is not entirely clear
.hasLintViolation(
2,
5,
"Annotations with parameters should all be placed on separate lines prior to the annotated construct"
)
.isFormattedAs(formattedCode)
and
@Disabled("To be implemented")
@Test
fun `Given a semi colon at the start of a line then do report a lint error`() {
val code =
"""
;val fooBar = "fooBar"
""".trimIndent()
val formattedCode =
"""
val fooBar = "fooBar"
""".trimIndent()
noSemicolonsRuleAssertThat(code)
.hasLintViolation(1, 1, "Unnecessary semicolon")
.isFormattedAs(formattedCode)
}
The text was updated successfully, but these errors were encountered:
During rewrite of tests (#1444) to using the KtLintAssertThat API, I encounted a number of situations in which a rule does seem to contain a bug. Most of them are simple off-by-one mistakes in the offset at which an error is found. Those situations can easily be found by searching for
TODO
and@Disabled
in the unit tests of the KtLint rules.Examples:
and
The text was updated successfully, but these errors were encountered: