Repeat format step until no more errors are found which can be auto-corrected #2084
Assignees
Milestone
Comments
paul-dingemans
added a commit
that referenced
this issue
Jun 22, 2023
…also can be autocorrected Closes #2084 Do not require a blank line between the class/method signature and a nested declaration in rule blank-line-before-declaration. Allow branches with empty blocks in if-else. Emit violation which can not be autocorrected in case wrapping the operator reference in a binary expression would still violate the max-line-length. Only emit violation in if-else-wrapping rule in case a newline is missing. An incorrect indent should not lead to a violation about a missing newline. Swap the order in which the binary-expression-wrapping and argument-list-wrapping rules run. Binary expressions containing call expressions, or vice versa, are not autocorrected as it needs manual intervention whether it is better to wrap the operation reference or the argument value.
6 tasks
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
The order in which rules are executed can be influences with
Rule.VisitorModifier. Now the network or rule execution dependencies get more complex, it becomes difficult to find that single order of rules which always resolves all format errors in a single trip. This is confusing for users of kltint.If format finds any lint violations in a file that can be autocorrected, it should automatically rerun format on that file before returning the lint violations of the last format run. To prevent that a set of rules cause an infinite rerun of the format, no more than 3 reruns will be executed before returning the results.
The text was updated successfully, but these errors were encountered: